[PATCH 2/2] contrib/m920x/m920x_parse.pl: silence a warning
Silence a warning due to the way get_line() is supposed to be called:
Use of uninitialized value $cmd in split at m920x_parse.pl line 118
Signed-off-by: Antonio Ospite
---
contrib/m920x/m920x_parse.pl |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/m920x/m920x_parse.pl b/contrib/m920x/m920x_parse.pl
index a6ca80a..19ff71d 100755
--- a/contrib/m920x/m920x_parse.pl
+++ b/contrib/m920x/m920x_parse.pl
@@ -190,7 +190,7 @@ my @bytes;
if ($mode eq "fw") {
open(OUT, ">", "fw") || die "Can't open fw";
- while(@bytes = get_line()) {
+ while(@bytes = get_line("-1")) {
if(scalar(@bytes) <= 1) {
last;
}
--
1.7.10.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
[PATCH 1/2] contrib/m920x/m920x_parse.pl: stricter check when extracting firmware
Extract firmware only from the right messages, skip the other messages.
Signed-off-by: Antonio Ospite
---
contrib/m920x/m920x_parse.pl |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
mode change 100644 => 100755 contrib/m920x/m920x_parse.pl
diff --git a/contrib/m920x/m920x_parse.pl b/contrib/m920x/m920x_parse.pl
old mode 100644
new mode 100755
index b309250..a6ca80a
--- a/contrib/m920x/m920x_parse.pl
+++ b/contrib/m920x/m920x_parse.pl
@@ -195,8 +195,9 @@ if ($mode eq "fw") {
last;
}
+ my $is_fw_msg = $bytes[0] eq "40" && $bytes[1] eq "30";
my $len = hex($bytes[6] . $bytes[7]);
- if ($len < 32) {
+ if (!$is_fw_msg || $len < 32) {
next;
}
--
1.7.10.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
[PATCH 0/2] v4l-utils: some fixes for contrib/m920x/m920x_parse.pl
Here are a couple of fixes for the contrib/m920x/m920x_parse.pl script. Patch 01 makes extracting firmwares more robust, my previous tests were on a trimmed down USB dump so I missed the need for stricter checks, now I tested the script with a pristine dump pre-processed with parse-sniffusb2.pl and the firmware can be extracted with no problems. Patch 02 works around a warning. Antonio Ospite (2): contrib/m920x/m920x_parse.pl: stricter check when extracting firmware contrib/m920x/m920x_parse.pl: silence a warning contrib/m920x/m920x_parse.pl |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? -- 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
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Sat Dec 29 19:00:17 CET 2012 git hash:b858c331cdf402853be2c48c8f4f77173ef04da8 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: ERRORS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-i686: WARNINGS linux-3.7-i686: WARNINGS linux-3.8-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-x86_64: WARNINGS linux-3.7-x86_64: WARNINGS linux-3.8-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.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: ABI breakage due to "Unsupported formats in TRY_FMT/S_FMT" recommendation
Em Sat, 29 Dec 2012 14:52:14 -0500 Devin Heitmueller escreveu: > On Sat, Dec 29, 2012 at 9:23 AM, Mauro Carvalho Chehab > wrote: > > On a tvtime compiled without libv4l, the cx18 driver will fail with the > > current logic, as it doesn't return an error when format doesn't > > match. So, tvtime will fail anyway with 50% of the TV drivers that don't > > support YUYV directly. It will also fail with most cameras, as they're > > generally based on proprietary/bayer formats and/or may not have the > > resolutions that tvtime requires. > > > > That's said, libv4l does format conversion. So, if the logic on libv4l > > is working properly, and as tvtime does upport libv4l upstream, > > no real bug should be seen with tvtime, even if the device doesn't > > support neither UYVY or YUYV. > > Tvtime doesn't use libv4l (and never has), unless you added support > very recently and it's not in the linuxtv.org tree. No, I didn't add. Not sure why I was thinking that support for it was added. > I started to look > into making it use libv4l some months back, but libv4l only supports > providing the video to the app in a few select formats (e.g. RGB > formats and YUV 4:2:0). Tvtime specifically needs the video in YUYV > or UYVY because it does all its overlays directly onto the video > buffer, the deinterlacers expect YUYV, and the XVideo support in the > app currently only does YUYV. > > Changing the app to work with 4:2:0 would mean cleaning up the rats > nest that does all of the above functions - certainly not impossible, > but not trivial either. In fact, it would probably be better to add > the colorspace conversion code to libv4l to support providing YUYV to > the app when it asks for it. Agreed. Adding YUYV support at libv4l should be easy. > > The above also applies to MythTV, except that I'm not sure if MythTV uses > > libv4l. > > It does not. > > There's no doubt that both MythTV and Tvtime could use an overhaul of > their V4L2 code (which became as nasty as it is primarily due to all > the years of the kernel's lack of specified behavior and failure to > enforce consistency across boards). That's not really relevant to the > discussion at hand though, which is about breaking existing > applications (and possibly all the apps other than the two or three > common open source apps I raised as examples). Well, xawtv won't break, even without libv4l. Codes based on it won't likely break either. Applications that use libv4l will do whatever behavior libv4l does. I suspect your couple examples are the most used applications that don't fit into either case. So, in order to make the kernel drivers consistent, we need to know what other applications that don't use libv4l and would behave bad with driver changes at VIDIOC_S_FMT's way to return data to implement what it is at the specs. Then, work on a solution that will work everywhere. We can only touch the drivers afer being sure that no regressions will happen. > I would love to take a half dozen tuner boards of various types and > spend a week cleaning up Myth's code, but frankly I just don't have > the time/energy to take on such a task. > > Devin > -- 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: ABI breakage due to "Unsupported formats in TRY_FMT/S_FMT" recommendation
Em Sat, 29 Dec 2012 12:39:11 -0500 Devin Heitmueller escreveu: > > I suspect that the behavior of returning an error if a pixelformat is not > > supported is a leftover from the V4L1 API (VIDIOCSPICT). When drivers were > > converted to S/TRY_FMT this method of handling unsupported pixelformats was > > probably never changed. And quite a few newer drivers copy-and-pasted that > > method. Drivers like cx18/ivtv that didn't copy-and-paste code looked at the > > API and followed what the API said. > > > > At the moment most TV drivers seem to return an error, whereas for webcams > > it is hit and miss: uvc returned an error (until it was fixed recently), > > gspca didn't. So webcam applications probably do the right thing given the > > behavior of gspca. > > What if we returned an error but still changed the struct to specify > the supported format? That's not what the spec says, but it seems > like that's what is implemented in many drivers today and what many > applications expect to happen. That sounds a very bad idea: when an error rises, applications should not trust on any returned value, except for the returned error code itself. All the other values can be on some random state. This is perhaps the only behavior that are consistent on all ioctls of the media subsystem (and likely on the other ioctl's of the Kernel). > No doubt, this is a mess, and if we had tighter enforcement and better > specs before this stuff went upstream years ago, we wouldn't be in > this situation. But that's not the world we live in, and we have to > deal with where we stand today. Well, something needs to be done at Kernel level, in order to make this ioctl consistent among all drivers. I'm open to proposals. In any case, applications aren't implementing the same logic to handle this ioctl. This should be fixed there, in order to avoid unexpected troubles with different hardware. 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: ABI breakage due to "Unsupported formats in TRY_FMT/S_FMT" recommendation
On Sat, Dec 29, 2012 at 9:23 AM, Mauro Carvalho Chehab wrote: > On a tvtime compiled without libv4l, the cx18 driver will fail with the > current logic, as it doesn't return an error when format doesn't > match. So, tvtime will fail anyway with 50% of the TV drivers that don't > support YUYV directly. It will also fail with most cameras, as they're > generally based on proprietary/bayer formats and/or may not have the > resolutions that tvtime requires. > > That's said, libv4l does format conversion. So, if the logic on libv4l > is working properly, and as tvtime does upport libv4l upstream, > no real bug should be seen with tvtime, even if the device doesn't > support neither UYVY or YUYV. Tvtime doesn't use libv4l (and never has), unless you added support very recently and it's not in the linuxtv.org tree. I started to look into making it use libv4l some months back, but libv4l only supports providing the video to the app in a few select formats (e.g. RGB formats and YUV 4:2:0). Tvtime specifically needs the video in YUYV or UYVY because it does all its overlays directly onto the video buffer, the deinterlacers expect YUYV, and the XVideo support in the app currently only does YUYV. Changing the app to work with 4:2:0 would mean cleaning up the rats nest that does all of the above functions - certainly not impossible, but not trivial either. In fact, it would probably be better to add the colorspace conversion code to libv4l to support providing YUYV to the app when it asks for it. > The above also applies to MythTV, except that I'm not sure if MythTV uses > libv4l. It does not. There's no doubt that both MythTV and Tvtime could use an overhaul of their V4L2 code (which became as nasty as it is primarily due to all the years of the kernel's lack of specified behavior and failure to enforce consistency across boards). That's not really relevant to the discussion at hand though, which is about breaking existing applications (and possibly all the apps other than the two or three common open source apps I raised as examples). I would love to take a half dozen tuner boards of various types and spend a week cleaning up Myth's code, but frankly I just don't have the time/energy to take on such a task. 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: [linux-media] Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
Em Sat, 29 Dec 2012 18:49:21 +0100 Klaus Schmidinger escreveu: > On 29.12.2012 17:36, Devin Heitmueller wrote: > > On Fri, Dec 28, 2012 at 6:56 PM, Mauro Carvalho Chehab > > wrote: > >> The DVBv3 quality parameters are limited on several ways: > >> - Doesn't provide any way to indicate the used measure; > >> - Userspace need to guess how to calculate the measure; > >> - Only a limited set of stats are supported; > >> - Doesn't provide QoS measure for the OFDM TPS/TMCC > >>carriers, used to detect the network parameters for > >>DVB-T/ISDB-T; > >> - Can't be called in a way to require them to be filled > >>all at once (atomic reads from the hardware), with may > >>cause troubles on interpreting them on userspace; > >> - On some OFDM delivery systems, the carriers can be > >>independently modulated, having different properties. > >>Currently, there's no way to report per-layer stats; > >> This RFC adds the header definitions meant to solve that issues. > >> After discussed, I'll write a patch for the DocBook and add support > >> for it on some demods. Support for dvbv5-zap and dvbv5-scan tools > >> will also have support for those features. > > > > Hi Mauro, > > > > As I've told you multiple times in the past, where this proposal falls > > apart is in its complete lack of specificity for real world scenarios. > > > > You have a units field which is "decibels", but in what unit? 1 dB / > > unit? 0.1 db / unit? 1/255 db / unit? This particular issue is why > > the current snr field varies across even demods where we have the > > datasheets. Many demods reported in 0.1 dB increments, while others > > reported in 1/255 dB increments. > > > > What happens when you ask for the SNR field when there is so signal > > lock (on most demods the SNR registers return garbage in this case)? > > What is the return value to userland? What happens when the data is > > unavailable for some other reason? What happens when you have group > > of statistics being asked for in a single call and *one* of them > > cannot be provided for some reason (in which case you cannot rely on a > > simple errno value since it doesn't apply to the entire call)? > > > > You need to take a step back and think about this from an application > > implementors standpoint. Most app developers for the existing apps > > look to show two data points: a signal indicator (0-100%), and some > > form of SNR (usually in dB, plotted on a scale where something like 40 > > dB=100% [of course this max varies by modulation type]). What would I > > need to do with the data you've provided to show that info? Do I > > really need to be a background in signal theory and understand the > > difference between SNR and CNR in order to tell the user how good his > > signal is? > > > > Since as an app developer I typically only have one or two tuners, how > > the hell am I supposed to write a piece of code that shows those two > > pieces of information given the huge number of different combinations > > of data types that demods could return given the proposed API? > > > > We have similar issues for UNC/BER values. Is the value returned the > > number of errors since the last time the application asked? Is it the > > number of errors in the last two seconds? Is it the number of errors > > since I reached signal lock? Does asking for the value clear out the > > counter? How do we handle the case where I asked for the data for the > > first time ten minutes after I reached signal lock? Are drivers > > internally supposed to be polling the register and updating the > > counters even when the application doesn't ask for the data (to handle > > cases where the demod's registers only have an error count for the > > last second's worth of data)? > > > > And where the examples that show "typical values" for the different > > modulation types? For example, I'm no expert in DVB-C but I'm trying > > to write an app which can be used by those users. What range of > > values will the API typically return for that modulation type? What > > values are "good" values, which represent "excellent" signal > > conditions, and what values suggest that the signal will probably be > > failing? > > > > What happens when a driver doesn't support a particular statistic? > > Right now some drivers return -EINVAL, others just set the field to > > zero or 0x1fff (in which case the user is mislead to believe that > > there is no signal lock *all* the time). > > > > EXAMPLES EXAMPLES EXAMPLES. This is the whole reason that the API > > behaves inconsistently today - somebody who did one of the early > > demods returned in 1/255 dB format, and then some other developer who > > didn't have the first piece of hardware wrote a driver and because > > he/she didn't *know* what the field was supposed to contain (and > > couldn't try it his/herself), that developer wro
Re: [linux-media] Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
On 29.12.2012 17:36, Devin Heitmueller wrote: On Fri, Dec 28, 2012 at 6:56 PM, Mauro Carvalho Chehab wrote: The DVBv3 quality parameters are limited on several ways: - Doesn't provide any way to indicate the used measure; - Userspace need to guess how to calculate the measure; - Only a limited set of stats are supported; - Doesn't provide QoS measure for the OFDM TPS/TMCC carriers, used to detect the network parameters for DVB-T/ISDB-T; - Can't be called in a way to require them to be filled all at once (atomic reads from the hardware), with may cause troubles on interpreting them on userspace; - On some OFDM delivery systems, the carriers can be independently modulated, having different properties. Currently, there's no way to report per-layer stats; This RFC adds the header definitions meant to solve that issues. After discussed, I'll write a patch for the DocBook and add support for it on some demods. Support for dvbv5-zap and dvbv5-scan tools will also have support for those features. Hi Mauro, As I've told you multiple times in the past, where this proposal falls apart is in its complete lack of specificity for real world scenarios. You have a units field which is "decibels", but in what unit? 1 dB / unit? 0.1 db / unit? 1/255 db / unit? This particular issue is why the current snr field varies across even demods where we have the datasheets. Many demods reported in 0.1 dB increments, while others reported in 1/255 dB increments. What happens when you ask for the SNR field when there is so signal lock (on most demods the SNR registers return garbage in this case)? What is the return value to userland? What happens when the data is unavailable for some other reason? What happens when you have group of statistics being asked for in a single call and *one* of them cannot be provided for some reason (in which case you cannot rely on a simple errno value since it doesn't apply to the entire call)? You need to take a step back and think about this from an application implementors standpoint. Most app developers for the existing apps look to show two data points: a signal indicator (0-100%), and some form of SNR (usually in dB, plotted on a scale where something like 40 dB=100% [of course this max varies by modulation type]). What would I need to do with the data you've provided to show that info? Do I really need to be a background in signal theory and understand the difference between SNR and CNR in order to tell the user how good his signal is? Since as an app developer I typically only have one or two tuners, how the hell am I supposed to write a piece of code that shows those two pieces of information given the huge number of different combinations of data types that demods could return given the proposed API? We have similar issues for UNC/BER values. Is the value returned the number of errors since the last time the application asked? Is it the number of errors in the last two seconds? Is it the number of errors since I reached signal lock? Does asking for the value clear out the counter? How do we handle the case where I asked for the data for the first time ten minutes after I reached signal lock? Are drivers internally supposed to be polling the register and updating the counters even when the application doesn't ask for the data (to handle cases where the demod's registers only have an error count for the last second's worth of data)? And where the examples that show "typical values" for the different modulation types? For example, I'm no expert in DVB-C but I'm trying to write an app which can be used by those users. What range of values will the API typically return for that modulation type? What values are "good" values, which represent "excellent" signal conditions, and what values suggest that the signal will probably be failing? What happens when a driver doesn't support a particular statistic? Right now some drivers return -EINVAL, others just set the field to zero or 0x1fff (in which case the user is mislead to believe that there is no signal lock *all* the time). EXAMPLES EXAMPLES EXAMPLES. This is the whole reason that the API behaves inconsistently today - somebody who did one of the early demods returned in 1/255 dB format, and then some other developer who didn't have the first piece of hardware wrote a driver and because he/she didn't *know* what the field was supposed to contain (and couldn't try it his/herself), that developer wrote a driver which returned in 0.1 dB format. This needs to be defined *in the spec*, or else we'll end up with developers (both app developers and kernel develoeprs implementing new demods) guessing how the API should behave based on whatever hardware they have, which is how we got in this mess in the first place. In short, you need to describe typical usage scenarios in terms of what values the API s
Re: ABI breakage due to "Unsupported formats in TRY_FMT/S_FMT" recommendation
On Sat, Dec 29, 2012 at 6:53 AM, Hans Verkuil wrote: > In my opinion these are application bugs, and not ABI breakages. I'm not sure if you saw the email, but Linus seems to disagree with your assertion quite strongly: https://lkml.org/lkml/2012/12/23/75 The change as proposed results in a situation where apps worked fine, user upgrades kernel, and now apps are broken. That sounds a lot like: "If a change results in user programs breaking, it's a bug in the kernel. We never EVER blame the user programs. How hard can this be to understand?" > As Mauro > mentioned, some drivers don't return an error and so would always have failed > with these apps (examples: cx18/ivtv, gspca). Yeah, except uncompressed support is quite new with cx18, ivtv doesn't support uncompressed at all, and gspca is for webcams, not TV. > Do these apps even handle the case where TRY isn't implemented at all by the > driver? (hdpvr) I haven't looked at compressed formats. Tvtime doesn't support them at all, and MythTV uses a completely different code path for compressed capture. MythTV even has special code for the HD-PVR, which presumably was to work around API inconsistencies. > There is nothing in the spec that says that you will get an error if the > pixelformat isn't supported by the driver, in fact it says the opposite: > > "Very simple, inflexible devices may even ignore all input and always return > the default parameters." > > We are not in the business to work around application bugs, IMHO. We can of > course delay making these changes until those applications are fixed. Except those two applications aren't the only two applications in existence which make use of the V4L2 API. Oh, and applications are supposed to continue working unmodified through kernel upgrades. > I suspect that the behavior of returning an error if a pixelformat is not > supported is a leftover from the V4L1 API (VIDIOCSPICT). When drivers were > converted to S/TRY_FMT this method of handling unsupported pixelformats was > probably never changed. And quite a few newer drivers copy-and-pasted that > method. Drivers like cx18/ivtv that didn't copy-and-paste code looked at the > API and followed what the API said. > > At the moment most TV drivers seem to return an error, whereas for webcams > it is hit and miss: uvc returned an error (until it was fixed recently), > gspca didn't. So webcam applications probably do the right thing given the > behavior of gspca. What if we returned an error but still changed the struct to specify the supported format? That's not what the spec says, but it seems like that's what is implemented in many drivers today and what many applications expect to happen. No doubt, this is a mess, and if we had tighter enforcement and better specs before this stuff went upstream years ago, we wouldn't be in this situation. But that's not the world we live in, and we have to deal with where we stand today. 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: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
On Fri, Dec 28, 2012 at 6:56 PM, Mauro Carvalho Chehab wrote: > The DVBv3 quality parameters are limited on several ways: > - Doesn't provide any way to indicate the used measure; > - Userspace need to guess how to calculate the measure; > - Only a limited set of stats are supported; > - Doesn't provide QoS measure for the OFDM TPS/TMCC > carriers, used to detect the network parameters for > DVB-T/ISDB-T; > - Can't be called in a way to require them to be filled > all at once (atomic reads from the hardware), with may > cause troubles on interpreting them on userspace; > - On some OFDM delivery systems, the carriers can be > independently modulated, having different properties. > Currently, there's no way to report per-layer stats; > This RFC adds the header definitions meant to solve that issues. > After discussed, I'll write a patch for the DocBook and add support > for it on some demods. Support for dvbv5-zap and dvbv5-scan tools > will also have support for those features. Hi Mauro, As I've told you multiple times in the past, where this proposal falls apart is in its complete lack of specificity for real world scenarios. You have a units field which is "decibels", but in what unit? 1 dB / unit? 0.1 db / unit? 1/255 db / unit? This particular issue is why the current snr field varies across even demods where we have the datasheets. Many demods reported in 0.1 dB increments, while others reported in 1/255 dB increments. What happens when you ask for the SNR field when there is so signal lock (on most demods the SNR registers return garbage in this case)? What is the return value to userland? What happens when the data is unavailable for some other reason? What happens when you have group of statistics being asked for in a single call and *one* of them cannot be provided for some reason (in which case you cannot rely on a simple errno value since it doesn't apply to the entire call)? You need to take a step back and think about this from an application implementors standpoint. Most app developers for the existing apps look to show two data points: a signal indicator (0-100%), and some form of SNR (usually in dB, plotted on a scale where something like 40 dB=100% [of course this max varies by modulation type]). What would I need to do with the data you've provided to show that info? Do I really need to be a background in signal theory and understand the difference between SNR and CNR in order to tell the user how good his signal is? Since as an app developer I typically only have one or two tuners, how the hell am I supposed to write a piece of code that shows those two pieces of information given the huge number of different combinations of data types that demods could return given the proposed API? We have similar issues for UNC/BER values. Is the value returned the number of errors since the last time the application asked? Is it the number of errors in the last two seconds? Is it the number of errors since I reached signal lock? Does asking for the value clear out the counter? How do we handle the case where I asked for the data for the first time ten minutes after I reached signal lock? Are drivers internally supposed to be polling the register and updating the counters even when the application doesn't ask for the data (to handle cases where the demod's registers only have an error count for the last second's worth of data)? And where the examples that show "typical values" for the different modulation types? For example, I'm no expert in DVB-C but I'm trying to write an app which can be used by those users. What range of values will the API typically return for that modulation type? What values are "good" values, which represent "excellent" signal conditions, and what values suggest that the signal will probably be failing? What happens when a driver doesn't support a particular statistic? Right now some drivers return -EINVAL, others just set the field to zero or 0x1fff (in which case the user is mislead to believe that there is no signal lock *all* the time). EXAMPLES EXAMPLES EXAMPLES. This is the whole reason that the API behaves inconsistently today - somebody who did one of the early demods returned in 1/255 dB format, and then some other developer who didn't have the first piece of hardware wrote a driver and because he/she didn't *know* what the field was supposed to contain (and couldn't try it his/herself), that developer wrote a driver which returned in 0.1 dB format. This needs to be defined *in the spec*, or else we'll end up with developers (both app developers and kernel develoeprs implementing new demods) guessing how the API should behave based on whatever hardware they have, which is how we got in this mess in the first place. In short, you need to describe typical usage scenarios in terms of what values the API should be returning for diffe
Re: [linux-media] [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
On 29.12.2012 00:56, Mauro Carvalho Chehab wrote:
The DVBv3 quality parameters are limited on several ways:
- Doesn't provide any way to indicate the used measure;
- Userspace need to guess how to calculate the measure;
- Only a limited set of stats are supported;
- Doesn't provide QoS measure for the OFDM TPS/TMCC
carriers, used to detect the network parameters for
DVB-T/ISDB-T;
- Can't be called in a way to require them to be filled
all at once (atomic reads from the hardware), with may
cause troubles on interpreting them on userspace;
- On some OFDM delivery systems, the carriers can be
independently modulated, having different properties.
Currently, there's no way to report per-layer stats;
This RFC adds the header definitions meant to solve that issues.
After discussed, I'll write a patch for the DocBook and add support
for it on some demods. Support for dvbv5-zap and dvbv5-scan tools
will also have support for those features.
Signed-off-by: Mauro Carvalho Chehab
---
include/uapi/linux/dvb/frontend.h | 78 ++-
1 file changed, 77 insertions(+), 1 deletion(-)
v3: Just update http://patchwork.linuxtv.org/patch/9578/ to current tip
diff --git a/include/uapi/linux/dvb/frontend.h
b/include/uapi/linux/dvb/frontend.h
index c12d452..a998b9a 100644
--- a/include/uapi/linux/dvb/frontend.h
+++ b/include/uapi/linux/dvb/frontend.h
@@ -365,7 +365,21 @@ struct dvb_frontend_event {
#define DTV_INTERLEAVING 60
#define DTV_LNA 61
-#define DTV_MAX_COMMANDDTV_LNA
+/* Quality parameters */
+#define DTV_ENUM_QUALITY 45 /* Enumerates supported QoS parameters
*/
+#define DTV_QUALITY_SNR46
+#define DTV_QUALITY_CNR47
+#define DTV_QUALITY_EsNo 48
+#define DTV_QUALITY_EbNo 49
+#define DTV_QUALITY_RELATIVE 50
+#define DTV_ERROR_BER 51
+#define DTV_ERROR_PER 52
+#define DTV_ERROR_PARAMS 53 /* Error count at TMCC or TPS carrier */
+#define DTV_FE_STRENGTH54
+#define DTV_FE_SIGNAL 55
+#define DTV_FE_UNC 56
+
+#define DTV_MAX_COMMANDDTV_FE_UNC
typedef enum fe_pilot {
PILOT_ON,
@@ -452,12 +466,74 @@ struct dtv_cmds_h {
__u32 reserved:30;/* Align */
};
+/**
+ * Scale types for the quality parameters.
+ * @FE_SCALE_DECIBEL: The scale is measured in dB, typically
+ * used on signal measures.
+ * @FE_SCALE_LINEAR: The scale is linear.
+ * typically used on error QoS parameters.
+ * @FE_SCALE_RELATIVE: The scale is relative.
+ */
+enum fecap_scale_params {
+ FE_SCALE_DECIBEL,
+ FE_SCALE_LINEAR,
+ FE_SCALE_RELATIVE
+};
+
+/**
+ * struct dtv_status - Used for reading a DTV status property
+ *
+ * @value: value of the measure. Should range from 0 to 0x;
+ * @scale: Filled with enum fecap_scale_params - the scale
+ * in usage for that parameter
+ * @min: minimum value. Not used if the scale is relative.
+ * For non-relative measures, define the measure
+ * associated with dtv_status.value == 0.
+ * @max: maximum value. Not used if the scale is relative.
+ * For non-relative measures, define the measure
+ * associated with dtv_status.value == 0x.
+ *
+ * At userspace, min/max values should be used to calculate the
+ * absolute value of that measure, if fecap_scale_params is not
+ * FE_SCALE_RELATIVE, using the following formula:
+ * measure = min + (value * (max - min) / 0x)
+ *
+ * For error count measures, typically, min = 0, and max = 0x,
+ * and the measure represent the number of errors detected.
+ *
+ * Up to 4 status groups can be provided. This is for the
+ * OFDM standards where the carriers can be grouped into
+ * independent layers, each with its own modulation. When
+ * such layers are used (for example, on ISDB-T), the status
+ * should be filled with:
+ * stat.status[0] = global statistics;
+ * stat.status[1] = layer A statistics;
+ * stat.status[2] = layer B statistics;
+ * stat.status[3] = layer C statistics.
+ * and stat.len should be filled with the latest filled status + 1.
+ * If the frontend doesn't provide a global statistics,
+ * stat.has_global should be 0.
+ * Delivery systems that don't use it, should just set stat.len and
+ * stat.has_global with 1, and fill just stat.status[0].
+ */
+struct dtv_status {
+ __u16 value;
+ __u16 scale;
+ __s16 min;
+ __s16 max;
+} __attribute__ ((packed));
+
struct dtv_property {
__u32 cmd;
__u32 reserved[3];
union {
__u32 data;
struct {
+ __u8 len;
+ __u8 has_global;
+
Re: saa711x doesn't match in easycap devices (stk1160 bridged)
Hi Hans, On Sat, Dec 29, 2012 at 12:10 PM, Hans Verkuil wrote: > On Sat December 29 2012 15:25:08 Ezequiel Garcia wrote: >> Ccing a few more people to get some feedback. >> >> Toughts anyone? Have you ever seen this before? >> >> On Fri, Dec 28, 2012 at 11:13 AM, Ezequiel Garcia >> wrote: >> > Hi everyone, >> > >> > Some stk1160 users (a lot acually) are reporting that stk1160 is broken. >> > The reports come in the out of tree driver [1], but probably the issue >> > is in mainline too. >> > >> > Now, it seems to me the problem is the saa711x decoder can't get matched, >> > see a portion of dmesg. >> > >> > [89947.448813] usb 1-2.4: New device Syntek Semiconductor USB 2.0 >> > Video Capture Controller @ 480 Mbps (05e1:0408, interface 0, class 0) >> > [89947.448827] usb 1-2.4: video interface 0 found >> > [89948.200366] saa7115 21-0025: chip found @ 0x4a (ID 000) >> > does not match a known saa711x chip. >> > [89948.200555] stk1160: driver ver 0.9.3 successfully loaded >> > [...] >> > >> > I'm working on this right now, but would like to know, given the ID >> > seems to be NULL, >> > what would be the right thing to do here. >> > Perhaps, replacing the -ENODEV error by a just warning and keep going? >> > >> > Further debugging [2] shows the chip doesn't seem to have a proper >> > chipid (as expected): > > From what I understand these devices use a GM7113C device, not a SAA7113. > It sounds like a chinese clone of the SAA7113 to me that works *almost* the > same, but not quite. > Yes, that seems to be the case. > In that case the saa711x_id table should be extended with a gm7113c entry > and, if chosen, the chip ID check should be skipped. > > This means that the stk1160 driver can try probing for saa7115_auto, and if > that fails it should try probing for gm7113c explicitly. > > Note that this probing technique works for all saa711x devices from saa7111 > onwards, but it is only described explicitly in the datasheet for the saa7115. > So if they cloned the saa7113 based on the saa7113 datasheet, then this useful > but undocumented feature would not be included in their clone. > I understand. I'll work with the users that are reporting this to get the best way to "probe" for this crappy chip. Strangely, according to translated chinese GM7113c datasheet, the chip should return ID just as saa7113 does. It can't be **that** different, since legacy easycap driver has been reported to work fine (which is understandable since easycap driver does it's own saa7113 handling). This represents a regression for many users, thus my desire to obtain a fix soon. Thanks, -- Ezequiel -- 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
Gigabyte U8000-RH dvb-t tunner problem
Hi guy's, I have some problem with my new Gigabyte U8000-RH hybrid DVB-T and Analogue USB device. My idea is to use this dvb-t tuner together with my Raspberry Pi, XBMC and tvheadend. But now I try to use tuner in my notebook with Fedora 17 and kernel 3.6.10-2.fc17.x86_64 The device I thing is running correctly using the following instruction: 1)http://www.linuxtv.org/wiki/index.php/Gigabyte_U8000-RH 2)http://www.linuxtv.org/wiki/index.php/Xceive_XC3028/XC2028 I had firmware for DiBcom 7000PC DVB-T demodulator (dvb-usb-dib0700-1.20.fw) and only build the firmware for the XCeive xc2028/xc3028 tuner (xc3028-v27.fw): # In order to use, you need to: # 1) Download the windows driver with something like: # wget http://www.steventoth.net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip # ( find here: http://cdn.pinnaclesys.com/SupportFiles/PCTV%20Drivers/ReadmePCTV.htm ) # 2) Extract the file hcw85bda.sys from the zip into the current dir: # unzip -j HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip Driver85/hcw85bda.sys # 3) Download the extract script # wget http://linuxtv.org/hg/v4l-dvb/raw-file/3919b17dc88e/linux/Documentation/video4linux/extract_xc3028.pl # 3) run the script: # perl extract_xc3028.pl # 4) copy the generated file: # sudo cp xc3028-v27.fw /lib/firmware After that plug the device and result is this: # lsusb Bus 002 Device 004: ID 1044:7002 Chu Yuen Enterprise Co., Ltd Gigabyte U8000 DVB-T tuner # dmesg [19378.803038] usb 2-2: new high-speed USB device number 5 using ehci_hcd [19378.917940] usb 2-2: New USB device found, idVendor=1044, idProduct=7002 [19378.917947] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [19378.917952] usb 2-2: Product: U8000 [19378.917957] usb 2-2: Manufacturer: GIGABYTE [19378.917961] usb 2-2: SerialNumber: 000GA1000100065 [19378.918688] dvb-usb: found a 'Gigabyte U8000-RH' in cold state, will try to load a firmware [19408.947281] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' [19409.149523] dib0700: firmware started successfully. [19409.650179] dvb-usb: found a 'Gigabyte U8000-RH' in warm state. [19409.650284] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [19409.650421] DVB: registering new adapter (Gigabyte U8000-RH) [19409.870156] DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)... [19409.870328] xc2028 7-0061: creating new instance [19409.870333] xc2028 7-0061: type set to XCeive xc2028/xc3028 tuner [19409.870343] dvb-usb: Gigabyte U8000-RH successfully initialized and connected. [19409.871587] xc2028 7-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 # ls -l /dev/dvb/adapter0/ total 0 crw-rw+ 1 root video 212, 0 Dec 29 16:25 demux0 crw-rw+ 1 root video 212, 1 Dec 29 16:25 dvr0 crw-rw+ 1 root video 212, 3 Dec 29 16:25 frontend0 crw-rw+ 1 root video 212, 2 Dec 29 16:25 net0 OK...and now when I try to watch tv with kaffeine for example, I see this error in the dmesg: [19865.904923] dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0 [19865.904923] [19865.904931] xc2028 7-0061: Loading firmware for type=D2620 DTV8 (208), id . [19865.909805] dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0 [19865.909805] [19865.914677] dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0 [19865.914677] [19865.918803] dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0 [19865.918803] [19865.926801] dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0 [19865.926801] [19865.934799] dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0 [19865.934799] [19865.943177] dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0 [19865.943177] [19865.947298] dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0 [19865.947298] [19865.951428] dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0 [19865.951428] [19865.959425] dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0 [19865.959425] [19865.963550] dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0 [19865.963550] [19865.969551] dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0 [19865.969551] [19865.973675] dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0 [19865.973675] [19865.981675] dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0 [19865.981675] [19865.985800] dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0 [19865.985800] [19865.989925] dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0 [19865.989925] [19865.996802] dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0 [19865.996802] [19866.000923] dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0 [19866.000923] [19866.005054] dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0 [19866.005054] [19866.009174] dib0700: stk7700ph_xc3028_callback: unk
Re: saa711x doesn't match in easycap devices (stk1160 bridged)
On Sat December 29 2012 15:25:08 Ezequiel Garcia wrote: > Ccing a few more people to get some feedback. > > Toughts anyone? Have you ever seen this before? > > On Fri, Dec 28, 2012 at 11:13 AM, Ezequiel Garcia > wrote: > > Hi everyone, > > > > Some stk1160 users (a lot acually) are reporting that stk1160 is broken. > > The reports come in the out of tree driver [1], but probably the issue > > is in mainline too. > > > > Now, it seems to me the problem is the saa711x decoder can't get matched, > > see a portion of dmesg. > > > > [89947.448813] usb 1-2.4: New device Syntek Semiconductor USB 2.0 > > Video Capture Controller @ 480 Mbps (05e1:0408, interface 0, class 0) > > [89947.448827] usb 1-2.4: video interface 0 found > > [89948.200366] saa7115 21-0025: chip found @ 0x4a (ID 000) > > does not match a known saa711x chip. > > [89948.200555] stk1160: driver ver 0.9.3 successfully loaded > > [...] > > > > I'm working on this right now, but would like to know, given the ID > > seems to be NULL, > > what would be the right thing to do here. > > Perhaps, replacing the -ENODEV error by a just warning and keep going? > > > > Further debugging [2] shows the chip doesn't seem to have a proper > > chipid (as expected): >From what I understand these devices use a GM7113C device, not a SAA7113. It sounds like a chinese clone of the SAA7113 to me that works *almost* the same, but not quite. In that case the saa711x_id table should be extended with a gm7113c entry and, if chosen, the chip ID check should be skipped. This means that the stk1160 driver can try probing for saa7115_auto, and if that fails it should try probing for gm7113c explicitly. Note that this probing technique works for all saa711x devices from saa7111 onwards, but it is only described explicitly in the datasheet for the saa7115. So if they cloned the saa7113 based on the saa7113 datasheet, then this useful but undocumented feature would not be included in their clone. Regards, Hans -- 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: ABI breakage due to "Unsupported formats in TRY_FMT/S_FMT" recommendation
Em Sat, 29 Dec 2012 12:23:34 -0200 Mauro Carvalho Chehab escreveu: > Em Sat, 29 Dec 2012 12:53:45 +0100 > Hans Verkuil escreveu: > > > On Sat December 29 2012 01:27:44 Mauro Carvalho Chehab wrote: > > > Em Fri, 28 Dec 2012 14:52:24 -0500 > > > Devin Heitmueller escreveu: > > > > > > > Hi there, > > > > > > > > So I noticed that one of the "V4L2 ambiguities" discussed at the Media > > > > Workshop relates to expected behavior with TRY_FMT/S_FMT. > ... > > > Well, if applications will break with this change, then we need to revisit > > > the question, and decide otherwise, as it shouldn't break userspace. > > > > > > It should be noticed, however, that currently, some drivers won't > > > return errors when S_FMT/TRY_FMT requests invalid parameters. > > > > > > So, IMHO, what should be done is: > > > 1) to not break userspace; > > > 2) userspace apps should be improved to handle those drivers > > > that have a potential of breaking them; > > > 3) clearly state at the API, and enforce via compliance tool, > > > that all drivers will behave the same. > > > > In my opinion these are application bugs, and not ABI breakages. As Mauro > > mentioned, some drivers don't return an error and so would always have > > failed > > with these apps (examples: cx18/ivtv, gspca). > > It is both an application bug and a potential ABI breakage. > > Hmm... as MythTv and tvtime are meant to be used to watch TV, maybe we can > look on it using a different angle. > ... > The drivers that only support V4L2_PIX_FMT_UYVY seems to be > cx18, sta2x11_vip, au0828 and gspca (kinect, w996xcf). From those, > only cx18 and au0828 are TV drivers. > > On a tvtime compiled without libv4l, the cx18 driver will fail with the > current logic, as it doesn't return an error when format doesn't > match. So, tvtime will fail anyway with 50% of the TV drivers that don't > support YUYV directly. It will also fail with most cameras, as they're > generally based on proprietary/bayer formats and/or may not have the > resolutions that tvtime requires. Not sure if I was clear enough. In summary, what I'm saying is that: 1) userspace apps should be fixed, as they're currently broken for cx18, when libv4l support is disabled; 2) from kernelspace's perspective, it seems that the changes for the above affected drivers need to be postponed. If this bug happens only on tvtime and MythTV, then changes on drivers that don't support UYVY could be done anytime, but a yellow flag rised: we should be sure that other userspace applications and libv4l won't be affected before changing an existing kernel driver, as no regressions are accepted. 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: saa711x doesn't match in easycap devices (stk1160 bridged)
Ccing a few more people to get some feedback. Toughts anyone? Have you ever seen this before? On Fri, Dec 28, 2012 at 11:13 AM, Ezequiel Garcia wrote: > Hi everyone, > > Some stk1160 users (a lot acually) are reporting that stk1160 is broken. > The reports come in the out of tree driver [1], but probably the issue > is in mainline too. > > Now, it seems to me the problem is the saa711x decoder can't get matched, > see a portion of dmesg. > > [89947.448813] usb 1-2.4: New device Syntek Semiconductor USB 2.0 > Video Capture Controller @ 480 Mbps (05e1:0408, interface 0, class 0) > [89947.448827] usb 1-2.4: video interface 0 found > [89948.200366] saa7115 21-0025: chip found @ 0x4a (ID 000) > does not match a known saa711x chip. > [89948.200555] stk1160: driver ver 0.9.3 successfully loaded > [...] > > I'm working on this right now, but would like to know, given the ID > seems to be NULL, > what would be the right thing to do here. > Perhaps, replacing the -ENODEV error by a just warning and keep going? > > Further debugging [2] shows the chip doesn't seem to have a proper > chipid (as expected): > > [ 304.059917] stk1160_i2c_xfer: addr=4a > [ 304.084238] OK > [ 304.084483] stk1160_i2c_xfer: addr=4a > [ 304.084498] subaddr=0 write=0 > [ 304.108254] OK > [ 304.108276] stk1160_i2c_xfer: addr=4a > [ 304.108286] subaddr=0 > [ 304.132367] read=10 > [ 304.132378] OK > [ 304.132394] stk1160_i2c_xfer: addr=4a > [ 304.132403] subaddr=0 write=1 > [ 304.156269] OK > [ 304.156288] stk1160_i2c_xfer: addr=4a > [ 304.156297] subaddr=0 > [ 304.180490] read=10 > [ 304.180500] OK > [ 304.180514] stk1160_i2c_xfer: addr=4a > [ 304.180523] subaddr=0 write=2 > [ 304.204249] OK > [ 304.204268] stk1160_i2c_xfer: addr=4a > [ 304.204276] subaddr=0 > [ 304.228365] read=10 > [ 304.228374] OK > [ 304.228388] stk1160_i2c_xfer: addr=4a > [ 304.228397] subaddr=0 write=3 > [ 304.252267] OK > [ 304.252286] stk1160_i2c_xfer: addr=4a > [ 304.252295] subaddr=0 > [ 304.276363] read=10 > [ 304.276372] OK > [ 304.276386] stk1160_i2c_xfer: addr=4a > [ 304.276395] subaddr=0 write=4 > [ 304.300248] OK > [ 304.300266] stk1160_i2c_xfer: addr=4a > [ 304.300275] subaddr=0 > [ 304.324363] read=10 > [ 304.324373] OK > [ 304.324386] stk1160_i2c_xfer: addr=4a > [ 304.324394] subaddr=0 write=5 > [ 304.348250] OK > [ 304.348268] stk1160_i2c_xfer: addr=4a > [ 304.348277] subaddr=0 > [ 304.372364] read=10 > [ 304.372374] OK > [ 304.372387] stk1160_i2c_xfer: addr=4a > [ 304.372396] subaddr=0 write=6 > [ 304.396250] OK > [ 304.396266] stk1160_i2c_xfer: addr=4a > [ 304.396275] subaddr=0 > [ 304.420363] read=10 > [ 304.420372] OK > [ 304.420386] stk1160_i2c_xfer: addr=4a > [ 304.420395] subaddr=0 write=7 > [ 304.444253] OK > [ 304.444274] stk1160_i2c_xfer: addr=4a > [ 304.444283] subaddr=0 > [ 304.468364] read=10 > [ 304.468374] OK > [ 304.468389] stk1160_i2c_xfer: addr=4a > [ 304.468398] subaddr=0 write=8 > [ 304.492248] OK > [ 304.492266] stk1160_i2c_xfer: addr=4a > [ 304.492275] subaddr=0 > [ 304.516360] read=10 > [ 304.516370] OK > [ 304.516384] stk1160_i2c_xfer: addr=4a > [ 304.516392] subaddr=0 write=9 > [ 304.540248] OK > [ 304.540278] stk1160_i2c_xfer: addr=4a > [ 304.540291] subaddr=0 > [ 304.564638] read=10 > [ 304.564653] OK > [ 304.564675] stk1160_i2c_xfer: addr=4a > [ 304.564687] subaddr=0 write=a > [ 304.565874] OK > [ 304.565895] stk1160_i2c_xfer: addr=4a > [ 304.565904] subaddr=0 > [ 304.588370] read=10 > [ 304.588376] OK > [ 304.588386] stk1160_i2c_xfer: addr=4a > [ 304.588390] subaddr=0 write=b > [ 304.61] OK > [ 304.612241] stk1160_i2c_xfer: addr=4a > [ 304.612249] subaddr=0 > [ 304.636369] read=10 > [ 304.636380] OK > [ 304.636396] stk1160_i2c_xfer: addr=4a > [ 304.636405] subaddr=0 write=c > [ 304.660268] OK > [ 304.660288] stk1160_i2c_xfer: addr=4a > [ 304.660297] subaddr=0 > [ 304.684364] read=10 > [ 304.684374] OK > [ 304.684388] stk1160_i2c_xfer: addr=4a > [ 304.684396] subaddr=0 write=d > [ 304.708249] OK > [ 304.708267] stk1160_i2c_xfer: addr=4a > [ 304.708276] subaddr=0 > [ 304.732366] read=10 > [ 304.732375] OK > [ 304.732389] stk1160_i2c_xfer: addr=4a > [ 304.732398] subaddr=0 write=e > [ 304.756251] OK > [ 304.756270] stk1160_i2c_xfer: addr=4a > [ 304.756279] subaddr=0 > [ 304.780365] read=10 > > -- > Ezequiel > > [1] https://github.com/ezequielgarcia/stk1160-standalone/issues/14 > [2] > https://github.com/ezequielgarcia/stk1160-standalone/issues/14#issuecomment-11732376 -- Ezequiel -- 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: ABI breakage due to "Unsupported formats in TRY_FMT/S_FMT" recommendation
Em Sat, 29 Dec 2012 12:53:45 +0100 Hans Verkuil escreveu: > On Sat December 29 2012 01:27:44 Mauro Carvalho Chehab wrote: > > Em Fri, 28 Dec 2012 14:52:24 -0500 > > Devin Heitmueller escreveu: > > > > > Hi there, > > > > > > So I noticed that one of the "V4L2 ambiguities" discussed at the Media > > > Workshop relates to expected behavior with TRY_FMT/S_FMT. ... > > Well, if applications will break with this change, then we need to revisit > > the question, and decide otherwise, as it shouldn't break userspace. > > > > It should be noticed, however, that currently, some drivers won't > > return errors when S_FMT/TRY_FMT requests invalid parameters. > > > > So, IMHO, what should be done is: > > 1) to not break userspace; > > 2) userspace apps should be improved to handle those drivers > > that have a potential of breaking them; > > 3) clearly state at the API, and enforce via compliance tool, > > that all drivers will behave the same. > > In my opinion these are application bugs, and not ABI breakages. As Mauro > mentioned, some drivers don't return an error and so would always have failed > with these apps (examples: cx18/ivtv, gspca). It is both an application bug and a potential ABI breakage. Hmm... as MythTv and tvtime are meant to be used to watch TV, maybe we can look on it using a different angle. tvtime tries first V4L2_PIX_FMT_YUYV. If it fails, it tries V4L2_PIX_FMT_UYVY. The drivers that support YUYV directly are: $ git grep -l V4L2_PIX_FMT_YUYV drivers/media/usb drivers/media/pci drivers/media/pci/bt8xx/bttv-driver.c drivers/media/pci/cx23885/cx23885-video.c drivers/media/pci/cx25821/cx25821-video.c drivers/media/pci/cx88/cx88-video.c drivers/media/pci/meye/meye.c drivers/media/pci/saa7134/saa7134-video.c drivers/media/pci/zoran/zoran_driver.c drivers/media/usb/cx231xx/cx231xx-video.c drivers/media/usb/em28xx/em28xx-video.c drivers/media/usb/gspca/ov534.c drivers/media/usb/gspca/vc032x.c drivers/media/usb/s2255/s2255drv.c drivers/media/usb/stkwebcam/stk-sensor.c drivers/media/usb/stkwebcam/stk-webcam.c drivers/media/usb/tlg2300/pd-video.c drivers/media/usb/tm6000/tm6000-video.c drivers/media/usb/usbvision/usbvision-core.c drivers/media/usb/usbvision/usbvision-video.c drivers/media/usb/uvc/uvc_driver.c $ git grep -l V4L2_PIX_FMT_UYVY drivers/media/usb drivers/media/pci drivers/media/pci/bt8xx/bttv-driver.c drivers/media/pci/cx18/cx18-ioctl.c drivers/media/pci/cx18/cx18-streams.c drivers/media/pci/cx23885/cx23885-video.c drivers/media/pci/cx25821/cx25821-video.c drivers/media/pci/cx88/cx88-video.c drivers/media/pci/saa7134/saa7134-video.c drivers/media/pci/sta2x11/sta2x11_vip.c drivers/media/pci/zoran/zoran_driver.c drivers/media/usb/au0828/au0828-video.c drivers/media/usb/gspca/kinect.c drivers/media/usb/gspca/w996Xcf.c drivers/media/usb/s2255/s2255drv.c drivers/media/usb/stk1160/stk1160-v4l.c drivers/media/usb/stkwebcam/stk-sensor.c drivers/media/usb/stkwebcam/stk-webcam.c drivers/media/usb/tm6000/tm6000-core.c drivers/media/usb/tm6000/tm6000-video.c drivers/media/usb/uvc/uvc_driver.c The drivers that only support V4L2_PIX_FMT_UYVY seems to be cx18, sta2x11_vip, au0828 and gspca (kinect, w996xcf). From those, only cx18 and au0828 are TV drivers. On a tvtime compiled without libv4l, the cx18 driver will fail with the current logic, as it doesn't return an error when format doesn't match. So, tvtime will fail anyway with 50% of the TV drivers that don't support YUYV directly. It will also fail with most cameras, as they're generally based on proprietary/bayer formats and/or may not have the resolutions that tvtime requires. That's said, libv4l does format conversion. So, if the logic on libv4l is working properly, and as tvtime does upport libv4l upstream, no real bug should be seen with tvtime, even if the device doesn't support neither UYVY or YUYV. The above also applies to MythTV, except that I'm not sure if MythTV uses libv4l. > Do these apps even handle the case where TRY isn't implemented at all by the > driver? (hdpvr) I think most apps don't try. > There is nothing in the spec that says that you will get an error if the > pixelformat isn't supported by the driver, in fact it says the opposite: > > "Very simple, inflexible devices may even ignore all input and always return > the default parameters." > > We are not in the business to work around application bugs, IMHO. We can of > course delay making these changes until those applications are fixed. Delay such changes make sense for me. > I suspect that the behavior of returning an error if a pixelformat is not > supported is a leftover from the V4L1 API (VIDIOCSPICT). When drivers were > converted to S/TRY_FMT this method of handling unsupported pixelformats was > probably never changed. And quite a few newer drivers copy-and-pasted that > method. Yes, I suspect so. Yet, we should not break userspace. > Drivers like cx18/ivtv that didn't copy-and-paste code looked at the > API and followed what the AP
Re: [media-workshop] Barcelona Media Summit Report
Em Sat, 29 Dec 2012 14:00:33 +0100 Hans Verkuil escreveu: > On Sat December 29 2012 13:53:38 Mauro Carvalho Chehab wrote: > > Em Sat, 29 Dec 2012 10:08:13 -0200 > > Mauro Carvalho Chehab escreveu: > > > > > Hi Hans & others, > > > > > > Sorry, only today I had time to dig into the Barcelona's media summit > > > report. > > > > > > I have a few comments for it below. > > > > > > Regards, > > > Mauro > > > > > > Em Fri, 16 Nov 2012 13:58:54 +0100 > > > Hans Verkuil escreveu: > > ... > > > > Ok, as I'm about to add this at linuxtv website, I'm re-posting the final > > text after my review. > > > > There's a small format change, as I paste it on Libreoffice, in order to > > make easier to convert to html, but the content should be the one written > > by Hans, with my reviews. > > It might be useful to add a pointer to my second draft of the guidelines > for submitting patches: > > http://lwn.net/Articles/529490/ > > Just a suggestion... Hmm... I don't like very much to mangle the summary of a meeting with something that were discussed after that at the ML, as one of the meeting's results. Especially since that is just a draft which might even not be the final one. Also, in this specific case, I can't see much value on adding such info, as the meeting report already points that such document will be discussed and elaborated at the ML and later added at kernel's Documentation, even pointing to the place at docs where it will likely be. 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
[ANNOUNCE] complete notes of the Barcelona's mini-summit
I found some time today to review and to convert the Barcelona's summit notes that Hans Verkuil did, convert theminto html and publish. They're all available at: http://www.linuxtv.org/news.php?entry=2012-12-29.mchehab I also added there the presentation I did, plus the one Hans did. Maybe there might be one or two presentation slide decks missing. If you find anything wrong there, please ping me. Regards, 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: iMon Knob driver issue
Le 29/12/2012 13:31, Alexey Klimov a écrit :
> Hello Alexandre,
>
> On Sat, Dec 29, 2012 at 4:08 PM, Alexandre LISSY
> wrote:
>> Hello,
>>
>> Please find attached a small patch for the iMon Knob driver. I've been
>
> Could you please also add your Signed-off-by to the patch? It looks
> like it's missed.
>
Sure, sorry for forgetting this, here it is !
>From cca7718a9902a4d5cffbf158b5853980a08ef930 Mon Sep 17 00:00:00 2001
From: Alexandre Lissy
Date: Sun, 2 Sep 2012 20:35:20 +0200
Subject: [PATCH] fix: iMon Knob event interpretation issues
Events for the iMon Knob pad where not correctly interpreted, resulting
in buggy mouse movements (cursor going straight out of the screen), key
pad only generating KEY_RIGHT and KEY_DOWN events. A reproducer is:
int main(int argc, char ** argv)
{
char rel_x = 0x00; printf("rel_x:%d @%s:%d\n", rel_x, __FILE__, __LINE__);
rel_x = 0x0f; printf("rel_x:%d @%s:%d\n", rel_x, __FILE__, __LINE__);
rel_x |= ~0x0f; printf("rel_x:%d @%s:%d\n", rel_x, __FILE__, __LINE__);
return 0;
}
(running on x86 or amd64)
$ ./test
rel_x:0 @test.c:6
rel_x:15 @test.c:7
rel_x:-1 @test.c:8
(running on armv6)
rel_x:0 @test.c:6
rel_x:15 @test.c:7
rel_x:255 @test.c:8
Forcing the rel_x and rel_y variables as signed char fixes the issue.
Signed-off-by: Alexandre Lissy
---
drivers/media/rc/imon.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index 5dd0386..9d30ca9 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -1225,7 +1225,7 @@ static u32 imon_panel_key_lookup(u64 code)
static bool imon_mouse_event(struct imon_context *ictx,
unsigned char *buf, int len)
{
- char rel_x = 0x00, rel_y = 0x00;
+ signed char rel_x = 0x00, rel_y = 0x00;
u8 right_shift = 1;
bool mouse_input = true;
int dir = 0;
@@ -1301,7 +1301,7 @@ static void imon_touch_event(struct imon_context *ictx, unsigned char *buf)
static void imon_pad_to_keys(struct imon_context *ictx, unsigned char *buf)
{
int dir = 0;
- char rel_x = 0x00, rel_y = 0x00;
+ signed char rel_x = 0x00, rel_y = 0x00;
u16 timeout, threshold;
u32 scancode = KEY_RESERVED;
unsigned long flags;
--
1.7.10.4
Re: [media-workshop] Barcelona Media Summit Report
Em Sat, 29 Dec 2012 10:53:38 -0200 Mauro Carvalho Chehab escreveu: ... > - Tuner ownership: how should the tuner ownership be handled? The proposal > I wrote for this was accepted, with the addition that the code to handle > tuner ownership should be shared between DVB and V4L2. > I have my name > and Hans de Goede's name next to this topic, but I've forgotten what we >were supposed to do :-) The above obviously is not right ;) As far as I remember, it should be, instead: Hans de Goede, with the help of Hans Verkuil, will be working on an RFC code to handle tuner ownership for radio and video. -- 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: [media-workshop] Barcelona Media Summit Report
On Sat December 29 2012 13:53:38 Mauro Carvalho Chehab wrote: > Em Sat, 29 Dec 2012 10:08:13 -0200 > Mauro Carvalho Chehab escreveu: > > > Hi Hans & others, > > > > Sorry, only today I had time to dig into the Barcelona's media summit > > report. > > > > I have a few comments for it below. > > > > Regards, > > Mauro > > > > Em Fri, 16 Nov 2012 13:58:54 +0100 > > Hans Verkuil escreveu: > ... > > Ok, as I'm about to add this at linuxtv website, I'm re-posting the final > text after my review. > > There's a small format change, as I paste it on Libreoffice, in order to > make easier to convert to html, but the content should be the one written > by Hans, with my reviews. It might be useful to add a pointer to my second draft of the guidelines for submitting patches: http://lwn.net/Articles/529490/ Just a suggestion... Regards, Hans > > Regards, > Mauro > > - > > Barcelona Media Summit Report > > 1 Merging Process > = > The morning was spent discussing the merging process. Basically the number of > patch submissions increased from 200 a month two years ago to 700 a month > this > year. Mauro is unable to keep up with that flood and a solution needed to be > found. > > Mauro explained the current merge process, and after that the floor was opened > for discussions. > > One of the problems is that it can be difficult to categorize patches since > often they are just prefixed with [PATCH]. Depending on who mailed it that > might mean an urgent regression fix, a patch that's ready to be merged or a > patch that needs review. There is no reliable way of knowing that without > actually looking at the mail. > > One thing that we want to improve is to make sure that the regular > contributors > at least use well defined patch prefixes. That means that we need a standard > prefix for regression fixes that need to go into the current rcX kernel asap. > This will make it easy to recognize them. We also need a prefix for patches > that > we want to have reviewed before a final git pull request is posted. Laurent > will > work into extending patchwork to delegate patches to sub-maintainers when > they > arrive there. > > There is a distinction between RFC patches and patches you consider final > (i.e. > ready for merging), but want people to look at. RFC patches will typically > need > more work, but you want people to check it out and make sure you are going in > the right direction. Review patches are what you consider the final version, > but > you want to give people a final chance to comment on them before posting the > pull > request. > > We also want to improve the MAINTAINERS file: it must be complete (with the > exception of RC keymaps and RC/V4L2/DVB core, where that doesn't make > sense). > > A patch reviewed-by/acked-by from the actual person mentioned in the > MAINTAINERS file and that follows the submission rules can be considered > with enough review for its merge. Obviously, if someone > not responsible for the driver in question has good technical arguments why > it's wrong, then that should be taken into account. > > In addition, the current list of media driver maintainers in that file needs > to be validated: are all emails still current, and is everyone still willing > to maintain their driver? > > New drivers also must come with a MAINTAINERS entry. > > In other words, the MAINTAINERS file will become more important. > > The final decision we made was to appoint submaintainers of parts of the media > subsystem. Those submaintainers will take over Mauro's job for those parts > that they are responsible for, and make periodic pull requests to Mauro to > pull in the patches they have collected. > Mauro will still be doing a second review on such patches. > > The submaintainers will be: > > Mike Krufky: frontends/tuners/demodulators > . In addition he'll be a reviewer for DVB core patches. > Hans Verkuil: V4L2 drivers and video A/D and D/A subdev drivers (aka video > receivers and transmitters). In addition he'll be a reviewer for > V4L2 core patches. > Laurent Pinchart: sensor subdev drivers > Kamil Debski: codec (aka memory-to-memory) drivers > Hans de Goede: non-UVC USB webcam drivers > Guennadi Liakhovetski: soc-camera drivers > > In addition, certain SoC vendors will remain responsible for their own drivers > (Samsung, TI) and will keep sending them straight to Mauro. > > The first step is to get the MAINTAINERS file into shape and to improve > patchwork, after that we need to clearly document the new structure. > > 2 Requirements for New V4L2 Drivers > === > The next topic was to document the requirements for new drivers. > > For the staging tree we want drivers to compile cleanly at the time of > submission. > Typically, that is all it should take to be accepted into staging. > It should be noticed though that a driver submitted for staging is a driver > that a
Re: [media-workshop] Barcelona Media Summit Report
Em Sat, 29 Dec 2012 10:08:13 -0200 Mauro Carvalho Chehab escreveu: > Hi Hans & others, > > Sorry, only today I had time to dig into the Barcelona's media summit report. > > I have a few comments for it below. > > Regards, > Mauro > > Em Fri, 16 Nov 2012 13:58:54 +0100 > Hans Verkuil escreveu: ... Ok, as I'm about to add this at linuxtv website, I'm re-posting the final text after my review. There's a small format change, as I paste it on Libreoffice, in order to make easier to convert to html, but the content should be the one written by Hans, with my reviews. Regards, Mauro - Barcelona Media Summit Report 1 Merging Process = The morning was spent discussing the merging process. Basically the number of patch submissions increased from 200 a month two years ago to 700 a month this year. Mauro is unable to keep up with that flood and a solution needed to be found. Mauro explained the current merge process, and after that the floor was opened for discussions. One of the problems is that it can be difficult to categorize patches since often they are just prefixed with [PATCH]. Depending on who mailed it that might mean an urgent regression fix, a patch that's ready to be merged or a patch that needs review. There is no reliable way of knowing that without actually looking at the mail. One thing that we want to improve is to make sure that the regular contributors at least use well defined patch prefixes. That means that we need a standard prefix for regression fixes that need to go into the current rcX kernel asap. This will make it easy to recognize them. We also need a prefix for patches that we want to have reviewed before a final git pull request is posted. Laurent will work into extending patchwork to delegate patches to sub-maintainers when they arrive there. There is a distinction between RFC patches and patches you consider final (i.e. ready for merging), but want people to look at. RFC patches will typically need more work, but you want people to check it out and make sure you are going in the right direction. Review patches are what you consider the final version, but you want to give people a final chance to comment on them before posting the pull request. We also want to improve the MAINTAINERS file: it must be complete (with the exception of RC keymaps and RC/V4L2/DVB core, where that doesn't make sense). A patch reviewed-by/acked-by from the actual person mentioned in the MAINTAINERS file and that follows the submission rules can be considered with enough review for its merge. Obviously, if someone not responsible for the driver in question has good technical arguments why it's wrong, then that should be taken into account. In addition, the current list of media driver maintainers in that file needs to be validated: are all emails still current, and is everyone still willing to maintain their driver? New drivers also must come with a MAINTAINERS entry. In other words, the MAINTAINERS file will become more important. The final decision we made was to appoint submaintainers of parts of the media subsystem. Those submaintainers will take over Mauro's job for those parts that they are responsible for, and make periodic pull requests to Mauro to pull in the patches they have collected. Mauro will still be doing a second review on such patches. The submaintainers will be: Mike Krufky: frontends/tuners/demodulators . In addition he'll be a reviewer for DVB core patches. Hans Verkuil: V4L2 drivers and video A/D and D/A subdev drivers (aka video receivers and transmitters). In addition he'll be a reviewer for V4L2 core patches. Laurent Pinchart: sensor subdev drivers Kamil Debski: codec (aka memory-to-memory) drivers Hans de Goede: non-UVC USB webcam drivers Guennadi Liakhovetski: soc-camera drivers In addition, certain SoC vendors will remain responsible for their own drivers (Samsung, TI) and will keep sending them straight to Mauro. The first step is to get the MAINTAINERS file into shape and to improve patchwork, after that we need to clearly document the new structure. 2 Requirements for New V4L2 Drivers === The next topic was to document the requirements for new drivers. For the staging tree we want drivers to compile cleanly at the time of submission. Typically, that is all it should take to be accepted into staging. It should be noticed though that a driver submitted for staging is a driver that are meant to be promoted one day as a main driver, and someone will actively work on them. So, drivers that can't be promoted to a main driver won't be merged at staging (e. g. drivers for already supported hardware, utterly bogus drivers, ...). For inclusion of pure V4L2 drivers into the mainline kernel we require the following: Use struct v4l2_device for bridge drivers, use struct v4l2_subdev for sub-device drivers. Use the control framework for control handling. Use struct v4l
Re: iMon Knob driver issue
Hello Alexandre, On Sat, Dec 29, 2012 at 4:08 PM, Alexandre LISSY wrote: > Hello, > > Please find attached a small patch for the iMon Knob driver. I've been Could you please also add your Signed-off-by to the patch? It looks like it's missed. -- Best regards, Klimov Alexey -- 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
iMon Knob driver issue
Hello,
Please find attached a small patch for the iMon Knob driver. I've been
trying to reach the latest maintainer (Jarod Wilson) listed in the file
since last september, getting no reply (maybe my mail did not made it
through, or went to spam).
Basically, the issue is the same as described on this webpage:
http://www.arm.linux.org.uk/docs/faqs/signedchar.php. I've hit it while
running multiple distros on my Raspberry Pi and trying to use my remote
control.
I've already added it as a patch in OpenElec sources, successfully
fixing the issue in my case.
>From cca7718a9902a4d5cffbf158b5853980a08ef930 Mon Sep 17 00:00:00 2001
From: Alexandre Lissy
Date: Sun, 2 Sep 2012 20:35:20 +0200
Subject: [PATCH] fix: iMon Knob event interpretation issues
Events for the iMon Knob pad where not correctly interpreted, resulting
in buggy mouse movements (cursor going straight out of the screen), key
pad only generating KEY_RIGHT and KEY_DOWN events. A reproducer is:
int main(int argc, char ** argv)
{
char rel_x = 0x00; printf("rel_x:%d @%s:%d\n", rel_x, __FILE__,
__LINE__);
rel_x = 0x0f; printf("rel_x:%d @%s:%d\n", rel_x, __FILE__, __LINE__);
rel_x |= ~0x0f; printf("rel_x:%d @%s:%d\n", rel_x, __FILE__, __LINE__);
return 0;
}
(running on x86 or amd64)
$ ./test
rel_x:0 @test.c:6
rel_x:15 @test.c:7
rel_x:-1 @test.c:8
(running on armv6)
rel_x:0 @test.c:6
rel_x:15 @test.c:7
rel_x:255 @test.c:8
Forcing the rel_x and rel_y variables as signed char fixes the issue.
---
drivers/media/rc/imon.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index 5dd0386..9d30ca9 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -1225,7 +1225,7 @@ static u32 imon_panel_key_lookup(u64 code)
static bool imon_mouse_event(struct imon_context *ictx,
unsigned char *buf, int len)
{
- char rel_x = 0x00, rel_y = 0x00;
+ signed char rel_x = 0x00, rel_y = 0x00;
u8 right_shift = 1;
bool mouse_input = true;
int dir = 0;
@@ -1301,7 +1301,7 @@ static void imon_touch_event(struct imon_context *ictx,
unsigned char *buf)
static void imon_pad_to_keys(struct imon_context *ictx, unsigned char *buf)
{
int dir = 0;
- char rel_x = 0x00, rel_y = 0x00;
+ signed char rel_x = 0x00, rel_y = 0x00;
u16 timeout, threshold;
u32 scancode = KEY_RESERVED;
unsigned long flags;
--
1.7.9.5
Re: [media-workshop] Barcelona Media Summit Report
Hi Hans & others, Sorry, only today I had time to dig into the Barcelona's media summit report. I have a few comments for it below. Regards, Mauro Em Fri, 16 Nov 2012 13:58:54 +0100 Hans Verkuil escreveu: > Hi all, > > This is the report of the Barcelona Media Summit on November 8. For those who > were in attendence: please correct any mistakes I may have made. > > My presentation for the 'Minimum Requirements for New Drivers' and the 'V4L2 > Ambiguities' can be found here: > > http://hverkuil.home.xs4all.nl/presentations/ambiguities2.odp > > I'd appreciate it if other presentations shown during the meeting can be made > available as well. > > Enjoy! > > Hans > > Merging Process > === > > The morning was spent discussing the merging process. Basically the number of > patch submissions increased from 200 a month two years ago to 700 a month this > year. Mauro is unable to keep up with that flood and a solution needed to be > found. > > Mauro explained the current merge process, and after that the floor was opened > for discussions. > > One of the problems is that it can be difficult to categorize patches since > often they are just prefixed with [PATCH]. Depending on who mailed it that > might mean an urgent regression fix, a patch that's ready to be merged or a > patch that needs review. There is no reliable way of knowing that without > actually looking at the mail. > > One thing that we want to improve is to make sure that the regular > contributors > at least use well defined patch prefixes. That means that we need a standard > prefix for regression fixes that need to go into the current rcX kernel asap. > This will make it easy to recognize them. We also need a prefix for patches > that > we want to have reviewed before a final git pull request is posted. > Laurent will look into extending patchwork to have such patches be marked as > 'Under Review' automatically. Actually, 'Under Review' patchwork tag is used just to indicate that a patch got delegated to someone's queue, not that such patch is more critical. What it was agreed, instead, is that: "Laurent will work into extending patchwork to delegate patches to sub-maintainers when they arrive there." By splitting the patch when it arrives to the sub-maintainers trees, the time from when it arrives to when it starts to be seen by the delegated people reduces a lot. > There is a distinction between RFC patches and patches you consider final > (i.e. > ready for merging), but want people to look at. RFC patches will typically > need > more work, but you want people to check it out and make sure you are going in > the right direction. Review patches are what you consider the final version, > but > you want to give people a final chance to comment on them before posting the > pull > request. > > We also want to improve the MAINTAINERS file: it must be complete (with the > exception of RC keymaps, and the RC/V4L2/DVB core > where that doesn't make sense). > When posting review > patches the reviewed-by/acked-by from the actual person mentioned in the > MAINTAINERS file is sufficient to get the patch merged. It is not a sufficient requirement: it should still follow the submission rules, use the right API, doesn't reinvent the wheel, doesn't create private APIs, etc. I think you meant to say, instead: "A patch reviewed-by/acked-by from the actual person mentioned in the MAINTAINERS file and that follows the submission rules can be considered with enough review for its merge." > Obviously, if someone > not responsible for the driver in question has good technical arguments why > it's wrong, then that should be taken into account. > > In addition, the current list of media driver maintainers in that file needs > to be validated: are all emails still current, and is everyone still willing > to maintain their driver? > > New drivers also must come with a MAINTAINERS entry. > > In other words, the MAINTAINERS file will become more important. > > The final decision we made was to appoint submaintainers of parts of the media > subsystem. Those submaintainers will take over Mauro's job for those parts > that they are responsible for, and make periodic pull requests to Mauro to > pull in the patches they have collected. I'll still be analyzing the patches, as a double-review doesn't hurt. > > The submaintainers will be: > > - Mike Krufky: frontends/tuners/demodulators > In addition he'll be the reviewer for DVB core patches. As I commented before: s/the reviewer/a reviewer/ > - Hans Verkuil: V4L2 drivers and video A/D and D/A subdev drivers (aka video > receivers and transmitters). In addition he'll be the reviewer for > V4L2 core patches. As I commented before: s/the reviewer/a reviewer/ On both cases, we do want more reviewers for the core. > - Laurent Pinchart: sensor subdev drivers > - Kamil Debski: codec (aka memory-to-mem
[PATCH] lmedm04: correct I2C values to 7 bit addressing.
On Fri, 2012-12-28 at 22:04 -0200, Mauro Carvalho Chehab wrote:
> Em Sat, 29 Dec 2012 01:06:29 +0300
> "Igor M. Liplianin" escreveu:
>
> > On 27 декабрÑ_ 2012 19:33:38 Mauro Carvalho Chehab wrote:
> > > Hi Igor,
> > Hi Mauro,
> >
> > >
> > > Em Mon, 24 Dec 2012 11:23:56 +0300
> > >
> > > "Igor M. Liplianin" escreveu:
> > > > The following changes since commit
> > > > 8b2aea7878f64814544d0527c659011949d52358:
> > > > [media] em28xx: prefer bulk mode on webcams (2012-12-23 17:24:30
> > > > -0200)
> > > >
> > > > are available in the git repository at:
> > > > git://git.linuxtv.org/liplianin/media_tree.git ts2020_v3.9
> > > >
> > > > for you to fetch changes up to 2ff52e6f487c2ee841f3df9709d1b4e4416a1b15:
> > > > ts2020: separate from m88rs2000 (2012-12-24 01:26:12 +0300)
> > > >
>
> Applied, thanks.
Hi all,
The separation the lmedm04 fails on the ts2020 portion because the correct
I2C addressing.
So, it's time to correct the addressing in the remainder of lmedm04.
Tested all tuners.
Signed-off-by: Malcolm Priestley
---
drivers/media/usb/dvb-usb-v2/lmedm04.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/lmedm04.c
b/drivers/media/usb/dvb-usb-v2/lmedm04.c
index b5e1f73..f30c58c 100644
--- a/drivers/media/usb/dvb-usb-v2/lmedm04.c
+++ b/drivers/media/usb/dvb-usb-v2/lmedm04.c
@@ -627,8 +627,8 @@ static int lme2510_i2c_xfer(struct i2c_adapter *adap,
struct i2c_msg msg[],
gate = 5;
for (i = 0; i < num; i++) {
- read_o = 1 & (msg[i].flags & I2C_M_RD);
- read = i+1 < num && (msg[i+1].flags & I2C_M_RD);
+ read_o = msg[i].flags & I2C_M_RD;
+ read = i + 1 < num && msg[i + 1].flags & I2C_M_RD;
read |= read_o;
gate = (msg[i].addr == st->i2c_tuner_addr)
? (read)? st->i2c_tuner_gate_r
@@ -641,7 +641,8 @@ static int lme2510_i2c_xfer(struct i2c_adapter *adap,
struct i2c_msg msg[],
else
obuf[1] = msg[i].len + read + 1;
- obuf[2] = msg[i].addr;
+ obuf[2] = msg[i].addr << 1;
+
if (read) {
if (read_o)
len = 3;
@@ -895,27 +896,27 @@ static int lme2510_kill_urb(struct usb_data_stream
*stream)
}
static struct tda10086_config tda10086_config = {
- .demod_address = 0x1c,
+ .demod_address = 0x0e,
.invert = 0,
.diseqc_tone = 1,
.xtal_freq = TDA10086_XTAL_16M,
};
static struct stv0288_config lme_config = {
- .demod_address = 0xd0,
+ .demod_address = 0x68,
.min_delay_ms = 15,
.inittab = s7395_inittab,
};
static struct ix2505v_config lme_tuner = {
- .tuner_address = 0xc0,
+ .tuner_address = 0x60,
.min_delay_ms = 100,
.tuner_gain = 0x0,
.tuner_chargepump = 0x3,
};
static struct stv0299_config sharp_z0194_config = {
- .demod_address = 0xd0,
+ .demod_address = 0x68,
.inittab = sharp_z0194a_inittab,
.mclk = 8800UL,
.invert = 0,
@@ -944,7 +945,7 @@ static int dm04_rs2000_set_ts_param(struct dvb_frontend *fe,
}
static struct m88rs2000_config m88rs2000_config = {
- .demod_addr = 0xd0,
+ .demod_addr = 0x68,
.set_ts_params = dm04_rs2000_set_ts_param,
};
@@ -1054,7 +1055,7 @@ static int dm04_lme2510_frontend_attach(struct
dvb_usb_adapter *adap)
info("TUN Found Frontend TDA10086");
st->i2c_tuner_gate_w = 4;
st->i2c_tuner_gate_r = 4;
- st->i2c_tuner_addr = 0xc0;
+ st->i2c_tuner_addr = 0x60;
st->tuner_config = TUNER_LG;
if (st->dvb_usb_lme2510_firmware != TUNER_LG) {
st->dvb_usb_lme2510_firmware = TUNER_LG;
@@ -1070,7 +1071,7 @@ static int dm04_lme2510_frontend_attach(struct
dvb_usb_adapter *adap)
info("FE Found Stv0299");
st->i2c_tuner_gate_w = 4;
st->i2c_tuner_gate_r = 5;
- st->i2c_tuner_addr = 0xc0;
+ st->i2c_tuner_addr = 0x60;
st->tuner_config = TUNER_S0194;
if (st->dvb_usb_lme2510_firmware != TUNER_S0194) {
st->dvb_usb_lme2510_firmware = TUNER_S0194;
@@ -1087,7 +1088,7 @@ static int dm04_lme2510_frontend_attach(struct
dvb_usb_adapter *adap)
info("FE Found Stv0288");
st->i2c_tuner_gate_w = 4;
st->i2c_tuner_gate_r = 5;
- st->i2c_tuner_addr = 0xc0;
+ st->i2c_tuner_addr = 0x60;
st->tuner_config = TUNER_S7395;
if (st->dvb_usb_l
Re: ABI breakage due to "Unsupported formats in TRY_FMT/S_FMT" recommendation
On Sat December 29 2012 01:27:44 Mauro Carvalho Chehab wrote: > Em Fri, 28 Dec 2012 14:52:24 -0500 > Devin Heitmueller escreveu: > > > Hi there, > > > > So I noticed that one of the "V4L2 ambiguities" discussed at the Media > > Workshop relates to expected behavior with TRY_FMT/S_FMT. > > Specifically (from > > http://www.linuxtv.org/news.php?entry=2012-12-28.mchehab): > > > > === > > 1.4. Unsupported formats in TRY_FMT/S_FMT > > > > What should a driver return in TRY_FMT/S_FMT if the requested format > > is not supported (possible behaviors include returning the currently > > selected format or a default format). > > The spec says this: "Drivers should not return an error code unless > > the input is ambiguous", but it does not explain what constitutes an > > ambiguous input. In my opinion TRY/S_FMT should never return an error > > other than EINVAL (if the buffer type is unsupported) or EBUSY (for > > S_FMT if streaming is in progress). > > Should we make a recommendation whether the currently selected format > > or a default format should be returned? > > One proposal is to just return a default format if the requested > > pixelformat is unsupported. Returning the currently selected format > > leads to inconsistent results. > > Results: > > TRY_FMT/S_FMT should never return an error when the requested format > > is not supported. Drivers should always return a valid format, > > preferably a format that is as widely supported by applications as > > possible. > > Both TRY_FMT and S_FMT should have the same behaviour. Drivers should > > not return different formats when getting the same input parameters. > > The format returned should be a driver default format if possible > > (stateless behaviour) but can be stateful if needed. > > The API spec should let clear that format retuns may be different when > > different video inputs (or outputs) are selected. > > === > > > > Note that this will cause ABI breakage with existing applications. If > > an application expects an error condition to become aware that the > > requested format was not supported, that application will silently > > think the requested format was valid but in fact the driver is > > returning data in some other format. > > > > Tvtime (one of the more popular apps for watching analog television) > > is one such application that will broken. > > > > http://git.linuxtv.org/tvtime.git/blob/HEAD:/src/videoinput.c#l452 > > > > If YUVY isn't supported but UYVY is (for example, with the Hauppauge > > HVR-950q), the application will think it's doing YUYV when in fact the > > driver is returning UYVY. > > > > MythTV is a little better (it does ultimately store the format > > returned by the driver), however even there it depends on an error > > being returned in order to know to do userland format conversion. > > > > https://github.com/MythTV/mythtv/blob/master/mythtv/libs/libmythtv/recorders/NuppelVideoRecorder.cpp#L1367 > > > > Now it would be quite simple to change tvtime to use the expected > > behavior, but if backward compatibility with the ABI is of paramount > > importance, then we cannot proceed with this change as proposed. > > Don't misunderstand me - if I were inventing the API today then the > > proposed approach is what I would recommend - but since these parts of > > the ABI are something like ten years old, we have to take into account > > legacy applications. > > Thanks for pointing it! > > (c/c Hans, as he started those discussions) > > Well, if applications will break with this change, then we need to revisit > the question, and decide otherwise, as it shouldn't break userspace. > > It should be noticed, however, that currently, some drivers won't > return errors when S_FMT/TRY_FMT requests invalid parameters. > > So, IMHO, what should be done is: > 1) to not break userspace; > 2) userspace apps should be improved to handle those drivers > that have a potential of breaking them; > 3) clearly state at the API, and enforce via compliance tool, > that all drivers will behave the same. In my opinion these are application bugs, and not ABI breakages. As Mauro mentioned, some drivers don't return an error and so would always have failed with these apps (examples: cx18/ivtv, gspca). Do these apps even handle the case where TRY isn't implemented at all by the driver? (hdpvr) There is nothing in the spec that says that you will get an error if the pixelformat isn't supported by the driver, in fact it says the opposite: "Very simple, inflexible devices may even ignore all input and always return the default parameters." We are not in the business to work around application bugs, IMHO. We can of course delay making these changes until those applications are fixed. I suspect that the behavior of returning an error if a pixelformat is not supported is a leftover from the V4L1 API (VIDIOCSPICT). When drivers were converted to S/TRY_FMT this method of handling unsupported pixelformats was probably never c
