Re: RFCv1: v4l-dvb development models old kernel support
On Sunday 22 February 2009 02:15:51 kilg...@banach.math.auburn.edu wrote: Oldest supported Ubuntu kernel is 2.6.22 (7.10): This is a bit optimistic. Matter of fact, I just bought a brand new eeePC in January, on which Asus chose to install Xandros. The response to uname -r is (I put this on a separate line in order to highlight it) 2.6.21.4-eeepc Now, some might not think of Xandros as a leading distro. It certainly would not have been my first choice. The choice of such an old kernel confirms that impression. But the netbook hardware platform, I would say, is a rather important one. The point is, if one is going to start looking for kernels that are obviously too old to mess with but are in common use then one has to go back even beyond 2.6.22. If it were my choice, I wouldn't. I don't think these netbooks are relevant for us for the simple fact that the main use case of v4l-dvb on devices like this is the webcam, and that will obviously be supported by whatever linux version the manufactorer has installed. But it does raise the point that if we decide to drop support for kernels 2.6.22 then it is probably a good idea to make a snapshot first so people can still have the option to upgrade their v4l-dvb, even though that version isn't maintained anymore by us. Thank you for your feedback! Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: RFCv1: v4l-dvb development models old kernel support
On Sunday 22 February 2009 00:47:46 Adam Baker wrote: On Saturday 21 February 2009, Hans Verkuil wrote: The high rate of changes and new drivers means that keeping up the backwards compatibility becomes an increasingly heavy burden. This leads to two questions: 1) Can we change our development model in such a way that this burden is reduced? Possibly but even just spreading the burden better (and avoiding the compat code affecting the main tree in the case of i2c) would be a worthwhile change. 2) How far back do we want to support older kernels anyway? To the point that the effort expended on the compat work is balanced by the benefit of more testers. These questions are related, since changes in the development model has implications for the answer to the second question. 1: Alternatives to the development model I see the following options: A) Keep our current model. This also keeps the way we do our backwards compatibility unchanged. B) Switch to a git tree that tracks Linus' tree closely and we drop backwards compatibility completely. C) Switch to the ALSA approach (http://git.alsa-project.org/). Another example of this approach can be seen with the linux-wireless git tree. There is a description of the process at http://linuxwireless.org/en/users/Download#Developers It might be a more relevant example as there are changes in 2.6.27 that make it difficult to support older kernels. They therefore made a decision at that point to restrict the automated backporting to 2.6.27 onwards and say patches will be accepted to the compat tree that covers 2.6.21 to 2.6.26 if a driver change is compatible but they must be manually flagged as being suitable (I've no idea how many are). It does require one person (who isn't the main wireless maintainer) to be the maintainer of the compat tree. This would basically mean making a snapshot of the v4l-dvb repository, calling it v4l-dvb-old and relying on people to update it with fixes. I did think about this myself but I thought it unlikely that the old tree would see much work, if at all. It's what they are admitting to on the wireless site as well. This could be an option if we are faced with an incompatible kernel change, but in this particular case it is my gut-feeling that 2.6.22 is old enough that people can just upgrade to that release. And luckily, since the oldest kernel currently in regular use is 2.6.22 that makes a very good argument for dropping the i2c compatibility mess. Unfortunately this all omits one important point, are there any key developers for whom dropping support for old kernels will cause them a problem which could reduce their productivity. Mauro has stated that it would cause him a problem but I can't tell how big a problem it would really be. I'll start a poll. Let's see what the opinion is. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: Minimum kernel version supported by v4l-dvb
Hi Trent, On Sat, 21 Feb 2009 05:58:10 -0800 (PST), Trent Piepho wrote: On Sat, 21 Feb 2009, Jean Delvare wrote: Well, that's basically what Hans has been doing with v4l2-i2c-drv-legacy.h for months now, isn't it? This is the easy part (even though even this wasn't exactly trivial...) Last time I looked they didn't do this. They just allowed an i2c driver to provide both an old-style interface and a probe/remove interface (not detect, it wasn't around yet). I think it should be possible for a driver to provide a probe/remove/detect interface and work on old kernels with a compat layer than translates the old inform methods into the new methods. Ah, yes, my bad. Now I remember: I tried to extent Hans' code to add support for the detect() function, but failed. But maybe someone more familiar with it (either you or Hans) may succeed where I failed. The hard part is when you want to use pure new-style i2c binding (using i2c_new_device() or i2c_new_probed_device()) in the upstream kernel. There is simply no equivalent in pre-2.6.22 kernels. So no matter what Yes, that's the part that seems most difficult. But maybe it doesn't have to be such a problem? If someone writes a new driver and only wants to use i2c_new_device() style attachment, then they can just use the existing version system to mark it as 2.6.22+ or 2.6.26+ only. Don't provide backward compatibility for the driver and just avoid the problem. Just because some new embedded camera doesn't work on 2.6.18 doesn't mean everyone has to lose 2.6.18 support. You are right in theory, but in practice there are corner cases where it isn't that easy. The new binding model wasn't created for my own fun, it was created because it solves problems. For example, before Hans converted the zoran driver, i2c chips were sometimes misdetected when one had several different supported adapters in the same system. This no longer happens after the conversion. So we are left with two choices: * Convert the zoran driver and lose support for kernels 2.6.22. * Don't convert the zoran driver and live with the bug forever. I'd rather go with the first option. Another example: I am converting the ir-kbd-i2c driver to the new-style binding model at the moment. This driver was using the legacy binding model in an unusual way: the addresses being probed depended on the underlying adapter. This is something the detect() callback in the new binding model doesn't handle. While you can check for the underlying adapter in the detect() callback, this happens _after_ the addresses have been probed. So we could do it, however this would mean probing all possible addresses on all adapters. As you know, excessive probing can confuse some chips, so this is quite risky. Using the pure new-style binding model (no detect()) OTOH fits perfectly. More generally, the point of the new-style model (without detect()) is to avoid probes as much as possible. This makes module loading less risky _and_ significantly faster on some models. Restricting these benefits to new drivers doesn't sound exactly right. I guess we're back to the key point I was making in the beginning: backwards compatibility is nice when it comes at a reasonable price. When you start degrading the design of the upstream code in order to make backwards compatibility easier or even possible at all, something's wrong. Of course there are the existing drivers like tvaudio and bttv. In this case, regardless of compatibility concerns, maybe switching to entirely i2c_new_device() style attachment isn't the right thing to do? After all, if -detect() should never be used, why is it there and why do sensor drivers use it? Don't the myriad versions of tvcards with their various i2c chips attached seemingly at random have a lot in common with motherboards and sensor chips? You are right, the detect() callback is there to be used in some cases, and I have no problem with it being used for the bttv driver or any other v4l driver where it makes sense. But it shouldn't be forgotten that this approach has roughly the same problems as the legacy model was, which means that it should ideally only be used when the alternatives do not work. Thanks, -- Jean Delvare -- 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
POLL: for/against dropping support for kernels 2.6.22
Hi all, There are lot's of discussions, but it can be hard sometimes to actually determine someone's opinion. So here is a quick poll, please reply either to the list or directly to me with your yes/no answer and (optional but welcome) a short explanation to your standpoint. It doesn't matter if you are a user or developer, I'd like to see your opinion regardless. Please DO NOT reply to the replies, I'll summarize the results in a week's time and then we can discuss it further. Should we drop support for kernels 2.6.22 in our v4l-dvb repository? _: Yes _: No Optional question: Why: Thanks, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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
mercurial problems?
Hi, When I try to push changes to my tree I get these errors: pushing to ssh://hverk...@linuxtv.org/hg/~hverkuil/v4l-dvb-ng-ctrls searching for changes remote: ** unknown exception encountered, details follow remote: ** report bug details to http://www.selenic.com/mercurial/bts remote: ** or mercur...@selenic.com remote: ** Mercurial Distributed SCM (version 0.9.3) remote: Traceback (most recent call last): remote: File /usr/bin/hg.real, line 12, in ? remote: commands.run() remote: File /usr/lib/python2.4/site-packages/mercurial/commands.py, line 3000, in run remote: sys.exit(dispatch(sys.argv[1:])) remote: File /usr/lib/python2.4/site-packages/mercurial/commands.py, line 3223, in dispatch remote: return d() remote: File /usr/lib/python2.4/site-packages/mercurial/commands.py, line 3182, in lambda remote: d = lambda: func(u, repo, *args, **cmdoptions) remote: File /usr/lib/python2.4/site-packages/mercurial/commands.py, line 2291, in serve remote: s.serve_forever() remote: File /usr/lib/python2.4/site-packages/mercurial/sshserver.py, line 40, in serve_forever remote: while self.serve_one(): pass remote: File /usr/lib/python2.4/site-packages/mercurial/sshserver.py, line 47, in serve_one remote: if impl: impl() remote: File /usr/lib/python2.4/site-packages/mercurial/sshserver.py, line 201, in do_unbundle remote: fp.close() remote: UnboundLocalError: local variable 'fp' referenced before assignment abort: unexpected response: empty string And running hg-menu will result in this: hg-menu /usr/local/bin/hg-menu: line 185: /tmp/dialog21904: Read-only file system Connection to linuxtv.org closed. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: RFCv1: v4l-dvb development models old kernel support
Hi together, following this dicussion for some time, let me just add my solely personal view. I'll have to prepend that I'm only a user in terms of v4l-dvb, but do for instance quite a lot support for Eee PC netbooks. So some comments here in some sense urged me to jump into this discussion. Hans Verkuil schrieb: On Sunday 22 February 2009 02:15:51 kilg...@banach.math.auburn.edu wrote: Oldest supported Ubuntu kernel is 2.6.22 (7.10): This is a bit optimistic. Matter of fact, I just bought a brand new eeePC in January, on which Asus chose to install Xandros. The response to uname -r is (I put this on a separate line in order to highlight it) 2.6.21.4-eeepc Now, some might not think of Xandros as a leading distro. It certainly would not have been my first choice. The choice of such an old kernel confirms that impression. But the netbook hardware platform, I would say, is a rather important one. The point is, if one is going to start looking for kernels that are obviously too old to mess with but are in common use then one has to go back even beyond 2.6.22. If it were my choice, I wouldn't. I don't think these netbooks are relevant for us for the simple fact that the main use case of v4l-dvb on devices like this is the webcam, and that will obviously be supported by whatever linux version the manufactorer has installed. First to the netbook questions ...) I suppose that you Hans don't use any of these so called netbooks? Nevertheless these devices are common today, just for the fact, that they offer a good value for money, are powerful enough for all the day to day tasks a normal user may want to do and are sometimes the first ever experience of normal users with linux. Furthermore you have a device which weights around 1 kg and has roughly the size of an A5 piece of paper or slightly larger. Besides the netbooks there are other devices, that share the same kind of linux distributions - or to make it more specific - say the Asus Eee Box models, that also comes (if they come with linux) with a Asus specific kind of Xandros linux, which itself is based on Debian etch and also newer parts of Debian lenny / sid. Just looking at the people I know (sometimes consider as friends), nearly 1/3 of them own such a device. More than 3/4 of them sticks to the default linux, which certainly has its quirks and problems. Using any other linux distribution may introduce a very recent kernel or other recent parts of software - but it just swaps Asus Xandros specific problems with that of the particular distro or kernel. The netbook itself is - just my personal view of it - just a small kind of notebook device with sometime older (Celeron M353 cpu etc.) or in newer models Intel Atom based hardware. This also means, that a lot of people just use it as a notebook, which means they use some sort of peripherals. Nearly all of the people I know owning a netbook, don't use their netbook just as it came, all of them use some additional hardware, most prominently a lot using DVB usb devices, 3G modems, bluetooth or IrDA dongles, external video or webcam devices or adapters to provide legacy serial or parallel interface ports. A lot of such devices are not supported by the kernel modules, that are provides with the netbook, so one has to build additional kernel modules. Sometime from other source, that the actual kernel source. In this case it is very handy to be able to compile a fresh hg checkout. I don't want to bother you with a listing of cases in which people I know to use a specific device or me even helping them to get it running on such netbooks The point just is, that regardless of a device being classified as netbook or notebook it is a very naive point of view to say: a) that it will only be used with to integrated software, b) that a manufacturer and or distribution will jump every few weeks onto a recent kernel (which would be in some case a major task to install) and c) that every normal user has the abilities to master such a - in some sense complicated task - as building and installing a complete kernel (building a v4l-dvb checkout is a lot more easier). Second ...) ... you just to a more wider viewpoint, or even just try to understand that there may be just more things to consider as development. The kernel itself is a great piece of work and the development it takes is in some parts amazing. But - be honest - a kernel as such leads you nowhere. You have to have other kind of software to build upon it ... say a linux distribution. Here the first problem occurs, as distributions use different kernels and most often introduce there own changes (not only regarding the kernel). Also - if you have a running linux system, with sometimes very specific software needs, which in most cases takes a lot of work to get *it all together* running, you aren't easily changing lot of this, let it be kernel, distro or whatever. So apart from
Re: [linux-dvb] Can I use AVerTV Volar Black HD (A850) with Linux ?
Hi, thanks for your support Antti ! Hello and thank you for information, According to your previous post, you are correct. I did one of the most typical mistake when adding new usb-id:s :) (didn't increase .num_device_descs). Laurent Haond wrote: af9015_usb_probe: interface:0 af9015_read_config: IR mode:0 Is there remote at all? No there is not remote at all in the bundle. af9015_read_config: TS mode:1 af9015_read_config: [0] xtal:2 set adc_clock:28000 af9015_read_config: [0] IF1:36125 hmmm, typical IF for many DVB-T tuners but very strange for MXL5003S. Maxlinear uses normally / default 4570kHz. I think thats why it does not work. Could you change .if_freq to IF_FREQ_36125000HZ and test? Tried, but same results... AVerMedia seems to use many times very weird configurations that are not reference nor default ones. af9015_read_config: [0] MT2060 IF1:0 af9015_read_config: [0] tuner id:13 af9015_read_config: [1] xtal:2 set adc_clock:28000 af9015_read_config: [1] IF1:36125 af9015_read_config: [1] MT2060 IF1:1220 af9015_read_config: [1] tuner id:130 af9015_identify_state: reply:01 af9015_copy_firmware: af9015: command failed:2 af9015: firmware copy to 2nd frontend failed, will disable it dvb-usb: no frontend was attached by 'AVerMedia A850' dvb-usb: AVerMedia A850 successfully initialized and connected. No knowledge why it fails. I suspect wrong GPIO, again this is AverMedia device... You should take usb-sniff and look correct GPIO from there. I trying to do that, but i'm not able to find a recent and working repository for usbreplay and parser.pl Seems that http://mcentral.de/wiki/index.php5/Usbreplay is out of date, and that http://mcentral.de/hg/~mrec/usbreplay is no more available. Can you point me to a working repository where i can get them ? Thanks Laurent -- 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] dvb-api: update documentation, chapter1
Since dvb-api doc is still outdated by six years...
The following patch changes dvbapi.pdf as following:
___
- change from twosided book format to singlesided book format.
* By doing so, the readability is improved and on the right-hand side
is more space on every second page.
- change copyright notice on first page by adding 2008, 2009
www.linuxtv.org
- add The Linux DVB Developers http://www.linuxtv.org; to 'written by'
- increase API Version number to 5
- change Version Number and date
-- 24/07/2003V 1.0.0
++ 22/02/2009Version 1.1.0 - unstable version now, every time api
is changed version should be increased now
- chapter 1 - What you need to know
* added goal: consistent abstraction layer for
different digital TV hardware, allowing software applications to be
developed without hardware details as well as serving as driver
developers reference
* added comment: odd api version numbers = unstable - not to be used
for driver/app development
- chapter 1 - history
* add History of DVB API v 4
* add comment LinuxTV project beeing an independend and non-profit
community
* add reasons for DVB API v 5 and decision on Plumbers Conference 2008
towards S2API
- chapter 1 - Overview
* changed DVB PCI card wherever found, since API doesnt depend on
PCI bus
* changed MPEG picture and sound decoding to MPEG video and audio
decoding,
since mpeg picture is misleading
- fix some typos inside chapter 1
- fix Overfull \hbox warnings from chapter 1 (*only* chapter 1 for now..)
Signed-off-by: Winfried Koehler handygewinnsp...@gmx.de
___
Please response, comment, improve, review, apply. Do not ignore silently,
having a new API doc should be hard requirement for next kernel versions.
Regards, Winfried
diff -Nrup v4l-dvb-359d95e1d541/dvb-spec/dvbapi/dvbapi.tex
v4l-dvb-a7ea3df69673/dvb-spec/dvbapi/dvbapi.tex
--- v4l-dvb-359d95e1d541/dvb-spec/dvbapi/dvbapi.tex2009-02-22
17:07:48.123742503 +0100
+++ v4l-dvb-a7ea3df69673/dvb-spec/dvbapi/dvbapi.tex2009-02-21
17:33:29.557033066 +0100
@@ -1,4 +1,4 @@
-\documentclass[a4paper,10pt]{book}
+\documentclass[a4paper,10pt,oneside]{book}
\usepackage[dvips,colorlinks=true]{hyperref}
\usepackage{times}
diff -Nrup v4l-dvb-359d95e1d541/dvb-spec/dvbapi/intro.tex
v4l-dvb-a7ea3df69673/dvb-spec/dvbapi/intro.tex
--- v4l-dvb-359d95e1d541/dvb-spec/dvbapi/intro.tex2009-02-18
13:49:37.0 +0100
+++ v4l-dvb-a7ea3df69673/dvb-spec/dvbapi/intro.tex2009-02-22
16:03:12.610230293 +0100
@@ -7,36 +7,73 @@
The reader of this document is required to have some knowledge in the
area of digital video broadcasting (DVB) and should be familiar with
part I of the MPEG2 specification ISO/IEC 13818 (aka ITU-T H.222),
-i.e you should know what a program/transport stream (PS/TS) is and what is
-meant by a packetized elementary stream (PES) or an I-frame.
-
-Various DVB standards documents are available from
-\texttt{http://www.dvb.org/} and/or \texttt{http://www.etsi.org/}.
+i.e you should know what a program stream or transport stream (PS/TS) is
+and what is meant by a packetized elementary stream (PES) or an I-frame.
+Various DVB standards documents are available from
\texttt{http://www.dvb.org/}
+and/or \texttt{http://www.etsi.org/}.
It is also necessary to know how to access unix/linux devices and how
to use ioctl calls. This also includes the knowledge of C or C++.
+The goal of this API is to provide a consistent abstraction layer for
+different digital TV hardware, allowing software applications to be
+developed without hardware details as well as serving as driver
+developers reference.
+
+For this API documentation applies an even/odd versioning scheme, stating
+unstable or stable versions of that API. Only stable API versions should
+be used for developing drivers and applications.
+\newpage
\section{History}
-The first API for DVB cards we used at Convergence in late 1999
-was an extension of the Video4Linux API which was primarily
+The first API for DVB cards was used at Convergence in late 1999
+as an extension of the Video4Linux API which was primarily
developed for frame grabber cards.
+
+
As such it was not really well suited to be used for DVB cards and
their new features like recording MPEG streams and filtering several
section and PES data streams at the same time.
-In early 2000, we were approached by Nokia with a proposal for a new
+
+In early 2000, Convergence was approached by Nokia with a proposal for
a new
standard Linux DVB API.
As a commitment to the development of terminals based on open standards,
Nokia and Convergence made it available to all Linux developers and
published it on \texttt{http://www.linuxtv.org/} in September 2000.
-Convergence is the maintainer of the Linux DVB API.
-Together with the LinuxTV community (i.e. you, the reader of
Re: [PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb/
Douglas Schilling Landgraf wrote: Hi Mauro, Please pull from http://linuxtv.org/hg/~dougsland/v4l-dvb/ for the following: - v4l2-apps: Add parser for USB snoops captured from SniffUSB 2.0 It is not clear to me why this ended up in /v4l2-apps/test, as opposed to /v4l2/util -- can someone comment? Thanks. -- 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] How to pass camera Orientation to userspace
On Sun, 22 Feb 2009, Hans de Goede wrote: Hans Verkuil wrote: Hi Adam, Sorry for the late reply, it's been very busy. Same here :) On Wednesday 18 February 2009 01:30:52 Adam Baker wrote: (linux-omap included in distribution as lots of omap systems include cameras so this could be relevant there.) Background A number of the webcams now supported by v4l have sensors that are mounted upside down. Up to now this has been handled by having a table in libv4l of the USB IDs of affected cameras. This approach however fails to address two known cases (and probably more as yet unknown ones) where the USB ID is insufficient to determine the sensor orientation. In one of those cases (SQ-905) USB commands must be issued to the camera at probe time) to determine what sensor is fitted and in the other case (Genesys gl860) the camera can be pointed towards or away from the user and it swaps orientation when it is changed. It is possible that there are cameras that can use gravity sensors or similar to report how they are being held but such user driven orientation which may be intended for creative effect should probably be separated from this hardware related issue. Yes, I strongly agree with this. +1 3) Use an extra couple of bits in V4L2_BUF_FLAGS Pros: Simple to implement. Can change per frame without needing polling. Cons: Doesn't work for non libv4l apps that try to use the read() interface. Can't easily identify drivers that don't support it (does 0 mean not rotated or just not implemented). Can only be read when streaming (does that matter?) I think that matters, yes. I too can see it being usefull to get the orientation when not streaming. 4) Use some reserved bits from the v4l2_capability structure Pros: Less overhead than controls. Cons: Would require polling to support the case of a camera being turned toward / away from the user while streaming. Can't easily identify drivers that don't support it. 5) Use some reserved bits from the v4l2_input structure (or possibly the status word but that is normally only valid for current input) Pros: Less overhead than controls. Could support multiple sensors in one camera if such a beast exists. What does exist is devices with a video input (e.g. composite) and a camera input: each input will have different flags. Since these vflip/hflip properties do not change they can be enumerated in advance and you know what each input supports. Cons: Would require polling to support the case of a camera being turned toward / away from the user while streaming. Polling applies only to the bits that tell the orientation of the camera. See below for a discussion of this. Didn't we agree to separate orietation (as in sensor mounted upside down) and the user being able to rotate the camera (which i believe we called pivotting). For the orientation case, which is the case with the sq905X, we do not need to poll, as for pivotting, here is my proposal: Have both orientation and pivotting flags in the input flags. The pivotting flags will indicate the pivotting state at the moment of doing the ioctl (which may change later), so these indeed may need to be polled, unlike the orientation flags which will never change. Can't easily identify drivers that don't support it. Not too difficult to add through the use of a capability bit. Either in v4l2_input or (perhaps) v4l2_capability. +1 Another Pro is that this approach will also work for v4l2_output in the case of, say, rotated LCD displays. Using camera orientation bits in v4l2_buffer while capturing will work, but using similar bits for output will fail since the data is going in the wrong direction. The interest in detecting if a driver provides this informnation is to allow libv4l to know when it should use the driver provided information and when it should use its internal table (which needs to be retained for backward compatibility). With no detection capability the driver provided info should be ignored for USB IDs in the built in table. Thoughts please Is polling bad in this case? It is not something that needs immediate attention IMHO. The overhead for checking once every X seconds is quite low. Agreed, but it still is something which should be avoided if possible, implementing polling also means adding a lot of IMHO unneeded code on the userspace side. I would prefer to make the realtime pivotting state available to the app by adding flags containing the pivotting state at frame capture to the v4l2_buf flags. But if people dislike this, libv4l can simple poll the input now and then. Furthermore, it is only needed on devices that cannot do v/hflipping in hardware. Erm, no, since we decided we want to differentiate between sensor orientation and camera pivotting, I think the driver should not automagically do v/hflipping in the pivot case, this should be left up to userspace. Maybe the user actually wants to have an upside down
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-zoran
Hans Verkuil wrote: It took me several long weekends to get all this work done, but I think it's been very worthwhile. Kudos! Well done -- another positive change! Together these cards use the ... ks0127 i2c devices quick question(s) - is this what I think it is -- a remote controller IC ? If so, do you know who manufactures this IC? (I'm trying to connect the dots with the problematic ks003 and ks007 ICs found on some cards) -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-zoran
On Sun, 22 Feb 2009 13:32:08 -0500, CityK wrote: Hans Verkuil wrote: It took me several long weekends to get all this work done, but I think it's been very worthwhile. Kudos! Well done -- another positive change! I cant only second this. Yay! Together these cards use the ... ks0127 i2c devices quick question(s) - is this what I think it is -- a remote controller IC ? If so, do you know who manufactures this IC? (I'm trying to connect the dots with the problematic ks003 and ks007 ICs found on some cards) The KS0127 is a video decoder, and it's made by Samsung. -- Jean Delvare -- 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: POLL: for/against dropping support for kernels 2.6.22
Hans Verkuil wrote: Should we drop support for kernels 2.6.22 in our v4l-dvb repository? Yes Optional question: Why: Its causing skilled developers to waste time that would be better served in other areas. Because of that, these skilled volunteers are becoming frustrated and losing their interest in pressing forth. It causes unnecessary complexity. The golden rule is to keep things as simple as possible. It presents a hurdle to attracting new development talent (both corporate and individual). When upstream technical changes (such as i2c subsystem changes) have made backporting downstream a nightmare, it is time to seriously evaluate why you are even bothering doing such. The salient point is that it is absolutely illogical for volunteers to be catering to narrow commercial interests. - Arguments about appeasing the needs of Enterprise distro's are moot. V4L-DVB owes them nothing. Enterprise distro's are specifically that -- an enterprise's work; if they crave support, then they can put Hans (or whomever) on the payroll to backport for their specific needs. - Arguments about appeasing the needs of embedded distros/platforms are moot. V4L-DVB owes them nothing. Let those groups figure out and/or support such device needs on their own; else they can put Hans (or whomever) on the payroll. Those manufactures releasing products within this space will adapt to whatever V4L-DVB does.This space will not suddenly fall apart because of our decision. These entrepreneurs have entered this space specifically to exploit a market opportunity. If they exit, someone else will move in. Its simple free market dynamics. (As it is, they are getting a free lunch ... seriously, I think that when the embedded space looks at how bent over accommodating we currently are, they must be rubbing their hands together and gleefully repeating Flounders statement: Oh boy, is this great! (http://www.acmewebpages.com/midi/great.wav)) The V4L-DVB is lacking in strategic direction. Yesterday was the time to adopt one; so lets pick up one today! I believe the plan to currently backport to 2.6.22 but to bump/narrow the kernel support window to the ideal/easier_to_maintain 2.6.25, once express support from the big 3 desktop distos ends, is the most logical choice and the one which will have the most beneficial impact on the project's future. -- 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] ERRORS: armv5 armv5-ixp armv5-omap2 i686 m32r mips powerpc64 x86_64 v4l-dvb build
(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:Sun Feb 22 19:00:03 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 10653:359d95e1d541 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.16.61-armv5: OK linux-2.6.17.14-armv5: OK linux-2.6.18.8-armv5: OK linux-2.6.19.5-armv5: OK linux-2.6.20.21-armv5: OK linux-2.6.21.7-armv5: OK linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29-rc5-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-rc5-armv5-ixp: OK linux-2.6.27-armv5-omap2: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-rc5-armv5-omap2: OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29-rc5-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-rc5-m32r: OK linux-2.6.16.61-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-rc5-mips: WARNINGS linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29-rc5-powerpc64: WARNINGS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK 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-rc5-x86_64: WARNINGS fw/apps: OK spec: ERRORS sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc5): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.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
struct dvb_frontend not initialized correctly / random id value since MFE merge
Hi there! MFE patches added a variable id to struct dvb_frontend. This variable seems to be uninitialized for some drivers. The result is for my skystar2 card (using stv0299 frontend) it sometimes is 0 as it should but sometimes it is a random value, so I get this register message: DVB: registering adapter 1 frontend -10551321 (ST STV0299 DVB-S) The related kernel thread then also has a strange name like: kdvb-ad-1-fe--1 The same happens for my dvb-ttpci card using ves1x93 frontend. Now I wonder if all frontend drivers should be switched to use kzalloc instead of kmalloc for struct dvb_frontend, or if it is the bridge driver that should init the id-value. What about all other members of this struct? Will they be initialized correctly? Regards Matthias -- 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: PVR x50 corrupts ATSC 115 streams
David Engel wrote: I'll start with what worked. ... [test results of BER and UNC under varying configurations ] ... Steven Toth wrote: I think CityK confirmed that the nxt2004 driver statistics are probably bogus so I doubt you're going to get your 115's running with BER 0 regardless, which is unfortunate. FWIW: I'm not seeing any UNC, just the BER (which seems consistent to most, but not all, of David's results with varying configurations). Presently (and a situation that is unlikely to change), I don't have an older kernel built/installed with which I can test/confirm, but from memory, IIRC, I believe that it must have been from around ~2.6.22 that I recall error free femon output. -- 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
Twinhan mantis, any CAM support in progress
Any work in progress for CAM support on the 2033? Currently using, http://mercurial.intuxication.org/hg/s2-liplianin but I´ll switch to whatever has or will have CAM. Card info, 25.180805] Mantis :00:07.0: PCI INT A - GSI 18 (level, low) - IRQ 18 [ 25.180843] Mantis :00:07.0: setting latency timer to 64 [ 25.180856] irq: 18, latency: 64 [ 25.180858] memory: 0xfdffd000, mmio: 0xf884 [ 25.180865] found a VP-2033 PCI DVB-C device on (00:07.0), [ 25.180870] Mantis Rev 1 [1822:0008], irq: 18, latency: 64 [ 25.180876] memory: 0xfdffd000, mmio: 0xf884 [ 25.184211] MAC Address=[00:08:ca:1a:f0:60] snip [ 25.704672] mantis_frontend_init (0): Probing for CU1216 (DVB-C) [ 25.706090] TDA10021: i2c-addr = 0x0c, id = 0x7c [ 25.706107] mantis_frontend_init (0): found Philips CU1216 DVB-C frontend (TDA10021) @ 0x0c [ 25.706117] mantis_frontend_init (0): Mantis DVB-C Philips CU1216 frontend attach success [ 25.710822] DVB: registering adapter 0 frontend 0 (Philips TDA10021 DVB-C)... [ 25.712780] mantis_ca_init (0): Registering EN50221 device [ 25.714818] mantis_ca_init (0): Registered EN50221 device [ 25.714844] mantis_hif_init (0): Adapter(0) Initializing Mantis Host Interface /Henrik -- 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] How to pass camera Orientation to userspace
On Sun, 22 Feb 2009, Hans de Goede wrote: kilg...@banach.math.auburn.edu wrote: snip Hans and Adam, I am not sure how it fits into the above discussion, but perhaps it is relevant to point out that flags can be toggled. Here is what I mean: Suppose that we have two flags 01 and 10 (i.e. 2), and 01 signifies VFLIP and 10 signifies HFLIP. Then for an ordinary camera in ordinary position these are initialized as 00. If the ordinary camera is turned in some funny way (and it is possible to know that) then one or both of these flags gets turned off. But if it is a funny camera like some of the SQ905s the initial values are 1 and 1, because the sensor is in fact mounted upside down. Now, suppose that there is some camera in the future which, just like this, has the sensor upside down, and suppose that said hypothetical camera also has the ability to know that it has been turned over so what was upside down is now right side up. Well, all that one has to do is to flip the two bits from whatever they were to have instead the opposite values! Observe that this would take care of the orientation problem both for cameras which had the sensor mounted right in the first place, and for cameras which had the sensor mounted wrong in the first place. Just use the same two bits to describe the sensor orientation, and if there is any reason (based upon some ability to know that the camera orientation is now different) that the orientation should change, then just flip the bits as appropriate. Then it would be the job of the support module to provide proper initial values only for these bits, and everything else could be done later on, in userspace. Theodore Kilgore Theodore, We want to be able to differentiate between a cam which has its sensor mounted upside down, and a cam which can be pivotted and happens to be upside down at the moment, in case of any upside down mounted sensor, we will always want to compentsate, in case of a pivotting camera wether we compensate or not could be a user preference. So in you example of an upside down mounted sensor in a pivotting encasing and the encasing is pivotted 180 degrees we would have the hflip and vflip bits set for sensor orientation and we would have the pivotted 180 degrees bit set. If the user has choosen to compensate for pivotting the default, we would do nothing. But it is important to be able to differentiate between the 2. Hans, I am not sure if we are talking past each other, or what. But I was pointing out that the initial values of two bits can indicate the default orientation of the sensor, and this can be done permanently in the module, which transmits the initial setting of those two bits to anything up the line which is interested or curious to know those initial values. The information in those two bits will definitely tell whether the sensor is mounted upside down in the camera. For example, if it is mounted upside down, then they are both set in the module to on and exported therefrom. But if the sensor is mounted correctly, then both of them are set to off and similarly exported. Now if any application for any reason (such as knowing that the camera is upside down or is pointing in the opposite direction, or into a mirror) wants to change the defaults, all it has to do is to toggle the bits. But, hmmm. Perhaps there is the question about how the app knows that the camera is upside down or is pointed in another direction. If the camera has a gyroscope inside, for example, then it could be the camera which needs to tell to the app about the current orientation, or else the app would not have any way to know ... Is this the problem, then? For that kind of thing, one might need more than two bits in order to pass the needed information. Incidentally, I obviously agree about the need to pass the initial sensor orientation. So anything I say about this should be taken in that context. Theodore Kilgore -- 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: Fwd: [linux-dvb] dvico dual express incorrect firmware version readback!!!
sonof...@iinet.net.au wrote: On Mon Feb 16 22:51 , sonof...@iinet.net.au sent: I have done alot more testing and have found that it seems to be only after mythtv has accessed the device where this problem beings begins... Same result with the hg version updated tonight. I haven't had a chance to use another tv app yet as we are currently watching TV. I will send a further update later. Is anyone else actually seeing this Incorrect Firmware Version Readback error?? Is there something I am missing? (stupid kernel setup or something??)... Should I try and source the firmware again or is this unlikely to be the issue? Have you tested this outside MythTV (which is a huge layer of extra complexity) ? -- 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 Sony PlayTV to dibcom driver
I don't think the Patchwork tool picked it up, as I don't see it in the queue :( http://patchwork.kernel.org/project/linux-media/list/ I'm wondering it the quotations in the subject line are enough to throw the script off. Mauro, any ideas? -- 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: firmware
Matthias Schwarzott wrote: Btw. I also had a longer look at the firmeware page in wiki and removed that note about gentoo using hotplug-scripts as that is false since a long time. CityK you are right, I think most (if not all) current distributions use udev to create device nodes and upload firmware into the kernel. Yes this ebuild is there. But it is in some respect outdated, due to lack of maintaining. This ebuild fetches the original files get_dvb_firmware also fetches and the runs get_firmware to unpack them. (All this due to license/re-distribution issues as you all know). Okay, thanks Matthias. But: These URLs tend to no longer work after some time, as manufacturers update their drivers or web-pages :( So there should either be someone continuously updating them (in get_dvb_firmware and also here in copy). Or: We find someone ignoring the licenses and hosting the extracted files somewhere. Regards Matthias I think we are stuck with the former. But, fortunately, it looks like schollsky is willing to be the point man :) -- 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: Kworld atsc 110 nxt2004 init
Jonathan Isom wrote: Hi I was looking over my logs and I'm wondering is nxt200x: Timeout waiting for nxt2004 to init common No its not common or is this womething I need to worry about. I got one shortly before a lockup(No backtrace). Nothing was doing other than dvbstreamer sitting idle. I'll provide further logs if it should be needed. I would think that It would need to only be initialize at module load. Am I wrong in this thinking? in kernel drivers 2.6.28.4 Later Jonathan Quick! Get out of you house now, she's about to blow !!! Just kidding. I don't think its anything to worry about. The timeout is by design (see the nxt200x.ko module). I'm not sure why you've run up against this; it looks to have occurred several hours after initialization. Perhaps a quirk in the microcode of the demod caused it. -- 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] Giving Feedback (was Re: Klear?)
Stephen Rowles wrote: Only sending this to linux-dvb as I'm not signed up to the media list, and I'll probably get myself blacklisted from any future help by saying this ;) but... BANISHMENT for Rowles !!! Just kidding. Thanks for the insightful reply. -- 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] [Bulk] Problem with TV card's sound (SAA7134)
panagiotis takis_rs wrote: panagiotis takis_rs wrote: Hey!! I have a problem with my tv card(pinnacle pctv 310i) I can see image but i have no sound. I have tried both tvtime and kdetv. I have found this http://ubuntuforums.org/showthread.php?t=568528 . Is it related with my problem? My tv card give audio output with this way: direct cable connection from tv card to sound card ( same cable witch connect cdrom and soundcard ) I didn't read through the link you provided, but it appeared to be in regards to getting audio via DMA (using the card's 7134 chip to digitize the audio and send it over the PCI bus to the host system). You, on the other hand, indicate that you are attempting to use the method of running a patch cable between your TV card and sound card (meaning that the sound card will do the digitizing instead). Question: have you checked your audio mixer to make sure that any of the inputs are not muted? Yes i have. The only way i managed to get sound is these two commands: tvtime | arecord -D hw:2,0 -r 32000 -c 2 -f S16_LE | aplay - (out of sync) tvtime | sox -r 32000 -t alsa hw:2,0 -t alsa hw:0,1 | aplay - Which, as you likely know, is essentially going the DMA route and using the helper apps (sox, arecord) as tvtime currently doesn't support audio DMA. Hmm, if everything is unmuted, I have no idea why it isn't working simply via your patch cable ... last stab at this -- how about the leads on the patch cable itself; have you tried reversing the way one of the ends is plugged in? -- 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
[PULL] http://linuxtv.org/hg/~eandren/gspca-m5602/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jean-Francois, Please pull from my repository. It includes one critical fix which needs to go in 2.6.29. Best regards, Erik -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmhv7wACgkQN7qBt+4UG0Er+ACgsTPdORJWoDxsffxBNhXhXhMh lSAAnAq3hBaQ7VcWp5LMZ2KSaLUZV3m+ =8QB2 -END PGP SIGNATURE- -- 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: Newbie question about cheap 4ch security card
Riba Zoltán wrote: Hi, I want to get working this card under my Debian :(2.6.24-etchnhalf.1-686 on i686) http://www.zoneminder.com/wiki/index.php/Image:4ch_DVR_card.jpg But it doesn't want...: dmesg: bttv: driver version 0.9.17 loaded bttv: using 8 buffers with 2080k (520 pages) each for capture bttv: Host bridge needs ETBF enabled. bttv: Bt8xx card found (0). PCI: Found IRQ 15 for device :00:12.0 PCI: Sharing IRQ 15 with :00:07.2 PCI: Sharing IRQ 15 with :00:0b.0 FPCI: Sharing IRQ 15 with :00:12.1F bttv0: Bt878 (rev 17) at :00:12.0, irq: 15, latency: 32, mmio: 0xd7001000 bttv0: using: GrandTec Multi Capture Card (Bt878) [card=77,insmod option] bttv0: enabling ETBF (430FX/VP3 compatibilty) bttv0: gpio: en=, out= in=00f360ff [init] bt878 #0 [sw]: bus seems to be busy bttv0: tuner absent bttv0: registered device video0 bttv0: registered device vbi0 bttv0: PLL: 28636363 = 35468950 .. ok bt878: AUDIO driver version 0.0.0 loaded bt878: Bt878 AUDIO function found (0). PCI: Found IRQ 15 for device :00:12.1 PCI: Sharing IRQ 15 with :00:07.2 PCI: Sharing IRQ 15 with :00:0b.0 PCI: Sharing IRQ 15 with :00:12.0 bt878_probe: card id=[0x0], Unknown card.Exiting.. bt878: probe of :00:12.1 failed with error -22 lspci -vn no subsystem ID reported ... and no card id in dmesg ... I'm wondering if there is no EEPROM on the card also wondering if your card is different (i.e. a new revision) from the card 77 (GrandTec Multi Capture Card). What happens if you don't pass a modprobe parameter (i.e. comment out what you added in your relevant /etc/modprobe.conf file) and let the card autodetect ... (though, as maybe surmised from my above comment, I'm guessing a spectacular nothing ) -- 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: vbox cat's eye 3560 usb device
Amy Overmyer wrote: Lastly, are there any other IC components on the back or front of the PCB ? Can you provide pics (upload them to the wiki article)) ? The back only has a couple components, probably for electrical, no ICs. okay The front only has the cypress (100 pin pkg) chip and the NIM, with a couple small components, that I can't read what they are. The PCB is stamped osc by one of them and usbid on the other, so I'm guessing one is an oscillator and the other the PROM where the cold USB id is stored. okay. I rather imagine that your guesses are correct I opened up the NIM (hey, they're $30 at my local computer store right now, so even if I kill it, I have an extra), and I saw my old friend the BCM3510 (I have a 1rst gen air2pc pci card that works pretty well for me) Wow, I'm kind of surprised about that one -- I would have expected the NIM to have been a little more contemporary (given that I believe these devices (150/151/3560) came out in the ~2005 time frame). and a smaller chip marked tua6030 (or could be 6080, the writing is faint, but infineon doesn't look like they make an 6080). Yes, that would be 6030 I have photos but need to upload them. okay This device might also be close in design to the original Technisat Air2PC-ATSC-USB device (http://www.linuxtv.org/wiki/index.php/TechniSat_Air2PC-ATSC-USB) -- though, obviously it doesn't use a Flexcop controller ... I say might be, as I don't know what the USB bridge is in the Technisat device, nor the exact tuner module employed. Patrick might recall though -- 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] How to pass camera Orientation to userspace
kilg...@banach.math.auburn.edu wrote: On Sun, 22 Feb 2009, Hans de Goede wrote: kilg...@banach.math.auburn.edu wrote: snip Hans and Adam, I am not sure how it fits into the above discussion, but perhaps it is relevant to point out that flags can be toggled. Here is what I mean: Suppose that we have two flags 01 and 10 (i.e. 2), and 01 signifies VFLIP and 10 signifies HFLIP. Then for an ordinary camera in ordinary position these are initialized as 00. If the ordinary camera is turned in some funny way (and it is possible to know that) then one or both of these flags gets turned off. But if it is a funny camera like some of the SQ905s the initial values are 1 and 1, because the sensor is in fact mounted upside down. Now, suppose that there is some camera in the future which, just like this, has the sensor upside down, and suppose that said hypothetical camera also has the ability to know that it has been turned over so what was upside down is now right side up. Well, all that one has to do is to flip the two bits from whatever they were to have instead the opposite values! Observe that this would take care of the orientation problem both for cameras which had the sensor mounted right in the first place, and for cameras which had the sensor mounted wrong in the first place. Just use the same two bits to describe the sensor orientation, and if there is any reason (based upon some ability to know that the camera orientation is now different) that the orientation should change, then just flip the bits as appropriate. Then it would be the job of the support module to provide proper initial values only for these bits, and everything else could be done later on, in userspace. Theodore Kilgore Theodore, We want to be able to differentiate between a cam which has its sensor mounted upside down, and a cam which can be pivotted and happens to be upside down at the moment, in case of any upside down mounted sensor, we will always want to compentsate, in case of a pivotting camera wether we compensate or not could be a user preference. So in you example of an upside down mounted sensor in a pivotting encasing and the encasing is pivotted 180 degrees we would have the hflip and vflip bits set for sensor orientation and we would have the pivotted 180 degrees bit set. If the user has choosen to compensate for pivotting the default, we would do nothing. But it is important to be able to differentiate between the 2. Hans, I am not sure if we are talking past each other, or what. But I was pointing out that the initial values of two bits can indicate the default orientation of the sensor, and this can be done permanently in the module, which transmits the initial setting of those two bits to anything up the line which is interested or curious to know those initial values. The information in those two bits will definitely tell whether the sensor is mounted upside down in the camera. For example, if it is mounted upside down, then they are both set in the module to on and exported therefrom. But if the sensor is mounted correctly, then both of them are set to off and similarly exported. Now if any application for any reason (such as knowing that the camera is upside down or is pointing in the opposite direction, or into a mirror) wants to change the defaults, all it has to do is to toggle the bits. But, hmmm. Perhaps there is the question about how the app knows that the camera is upside down or is pointed in another direction. If the camera has a gyroscope inside, for example, then it could be the camera which needs to tell to the app about the current orientation, or else the app would not have any way to know ... Is this the problem, then? For that kind of thing, one might need more than two bits in order to pass the needed information. Yes that is what we are talking about, the camera having a gravity switch (usually nothing as advanced as a gyroscope). Also the bits we are talking about are in a struct which communicates information one way, from the camera to userspace, so there is no way to clear the bits to make the camera do something. 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: RFCv1: v4l-dvb development models old kernel support
On Sun, 22 Feb 2009, Tobias Stöber wrote: Hi together, following this dicussion for some time, let me just add my solely personal view. I'll have to prepend that I'm only a user in terms of v4l-dvb, but do for instance quite a lot support for Eee PC netbooks. So some comments here in some sense urged me to jump into this discussion. You raise interesting points and complicated issues. I do not know if there is any ideal solution -- except, perhaps, time. I, unfortunately, can can see all sides of the issue, too... Hans Verkuil schrieb: On Sunday 22 February 2009 02:15:51 kilg...@banach.math.auburn.edu wrote: Oldest supported Ubuntu kernel is 2.6.22 (7.10): This is a bit optimistic. Matter of fact, I just bought a brand new eeePC in January, on which Asus chose to install Xandros. The response to uname -r is (I put this on a separate line in order to highlight it) 2.6.21.4-eeepc snip I don't think these netbooks are relevant for us for the simple fact that the main use case of v4l-dvb on devices like this is the webcam, and that will obviously be supported by whatever linux version the manufactorer has installed. First to the netbook questions ...) I suppose that you Hans don't use any of these so called netbooks? Nevertheless these devices are common today, just for the fact, that they offer a good value for money, are powerful enough for all the day to day tasks a normal user may want to do and are sometimes the first ever experience of normal users with linux. Furthermore you have a device which weights around 1 kg and has roughly the size of an A5 piece of paper or slightly larger. Yes, indeed. And the Atom model, especially when upgraded to 2 gig of RAM, is far from a toy. It is a very powerful and fast machine. It compares quite well with the desktop system I was using until quite recently (single-core Sempron 2600+ with 1 gig of RAM) and also with the heavy laptop I was using until quite recently (old Dell Latitude C600 with 800mhz Mobile Celeron and 384 meg of PC100 RAM, max capacity 512 meg of RAM). So I fully expect the eeePC to be the machine that I use while traveling, going to conferences, giving presentations, and this means as well that it has to be, ultimately, a second (or third or fourth) development platform for me because that is what I am doing. For me, of course, this means that it will ultimately have to have a systematic kernel and software upgrade. But other problems impinge there. I mentioned that I am running a very contemporary distro on it, with a very contemporary kernel. But I have not removed the original installation yet. For example, right now the wireless works with the original installation, but the support for the RaLink2860 is not yet in a stock kernel. So an important hardware component is not easy to support. I have the ability and the patience to deal with a problem like this one. But I am obviously in a minority. Besides the netbooks there are other devices, that share the same kind of linux distributions - or to make it more specific - say the Asus Eee Box models, that also comes (if they come with linux) with a Asus specific kind of Xandros linux, which itself is based on Debian etch and also newer parts of Debian lenny / sid. Well, now the other side of me is speaking. I admire Debian. But I have never used it. Debian has been too often too far behind on too many things -- kernel, libc version, libtool version, you name it. Then there are distros which base themselves on Debian, but are not Debian, and thereby seem to gain the attention of hardware manufacturers. I do not understand. Have I mentioned a user who reported a new stillcam to me two months ago, and the first thing to do was to see if it is supported by a recent libgphoto2? Well, on his Debian workstation a newer libgphoto2 would have required a newer libtool. He uses the workstation in his job, so he did not want to mess with that. So at my urging he put Slax on an SD card for his eeePC, and the Slackware package libgphoto2-2.4.3 (and a couple of missing dependencies) and then finally was able to test the camera and yes it works and I posted an update to SVN yesterday evening, after 2 months of hassle. I have had other experiences with users of certain distros, experiences which were not nearly so positive. Part of my point here is that it is not only kernel development which is affected by dilatory distros. Userspace development is affected, too. Users are affected. Everyone is affected. Not just the kernel version is in question. Basic libraries are behind on their versions. An attempt to upgrade anything causes dependency hell. From my point of view, the only thing to do about the problem is to publicize it. One possible way to publicize it is to point out just how much trouble it causes. Just looking at the people I know (sometimes consider as friends), nearly 1/3 of them own such a device. More
Re: [RFC] How to pass camera Orientation to userspace
On Sun, 22 Feb 2009, Hans de Goede wrote: Yes that is what we are talking about, the camera having a gravity switch (usually nothing as advanced as a gyroscope). Also the bits we are talking about are in a struct which communicates information one way, from the camera to userspace, so there is no way to clear the bits to make the camera do something. First, I'd like to say I agree with most that the installed orientation of the camera sensor really is a different concept than the current value of a gravity sensor. It's not necessary, and maybe not even desirable, to handle them in the same way. I do not see the advantage of using reserved bits instead of controls. The are a limited number of reserved bits. In some structures there are only a few left. They will run out. Then what? Packing non-standard sensor attributes and camera sensor meta-data into a few reserved bits is not a sustainable policy. Controls on the other card are not limited and won't run out. Currently reserved bits and previously reserved but now in use bits look exactly the same. How does an app know if the bits are valid or not? More reserved bits? The control API is already designed to allow for enumeration of controls. Reserved bits have no meta-data to document them. An app sees that some bits in the input struct which were reserved when it was written are now set. What does this tell the app? Nothing. What can the app tell the user? Nothing. The control API provides for control meta-data. We have a means of enumeration, name, min, max, step size, and various flags to tell us about a control that wasn't already handled. Does this new gravity sensor have 45 degree resolution? The control's step size can show this even if only 90 degree rotations had been considered when gravity sensor support was first added to some other driver. At the very least, the app (and various existing utilities) can provide information about the controls to the user. -- 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: POLL: for/against dropping support for kernels 2.6.22
On Sun, 22 Feb 2009, Hans Verkuil wrote: Hi all, There are lot's of discussions, but it can be hard sometimes to actually determine someone's opinion. So here is a quick poll, please reply either to the list or directly to me with your yes/no answer and (optional but welcome) a short explanation to your standpoint. It doesn't matter if you are a user or developer, I'd like to see your opinion regardless. Please DO NOT reply to the replies, I'll summarize the results in a week's time and then we can discuss it further. Should we drop support for kernels 2.6.22 in our v4l-dvb repository? _: Yes _: No Yes Optional question: Why: This shall free human resources necessary for performing the switch to the full-kernel development model. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- 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] How to pass camera Orientation to userspace
On Sun, 22 Feb 2009, Hans de Goede wrote: Trent Piepho wrote: On Sun, 22 Feb 2009, Hans de Goede wrote: Yes that is what we are talking about, the camera having a gravity switch (usually nothing as advanced as a gyroscope). Also the bits we are talking about are in a struct which communicates information one way, from the camera to userspace, so there is no way to clear the bits to make the camera do something. First, I'd like to say I agree with most that the installed orientation of the camera sensor really is a different concept than the current value of a gravity sensor. It's not necessary, and maybe not even desirable, to handle them in the same way. I do not see the advantage of using reserved bits instead of controls. The are a limited number of reserved bits. In some structures there are only a few left. They will run out. Then what? Packing non-standard sensor attributes and camera sensor meta-data into a few reserved bits is not a sustainable policy. Controls on the other card are not limited and won't run out. Yes but these things are *not* controls, end of discussion. The control API is for controls, not to stuff all kind of cruft in. All kind of cruft belongs in the reserved bits of whatever field it can be stuffed in? Until the bits run out and then it belongs where? What is the difference? Why does it matter? Performance? Maintenance? Is there something that's not possible? I do not find end of discussion to be a very convincing argument. -- 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: POLL: for/against dropping support for kernels 2.6.22
On Sun, 22 Feb 2009, Hans Verkuil wrote: Hi all, There are lot's of discussions, but it can be hard sometimes to actually determine someone's opinion. So here is a quick poll, please reply either to the list or directly to me with your yes/no answer and (optional but welcome) a short explanation to your standpoint. It doesn't matter if you are a user or developer, I'd like to see your opinion regardless. Please DO NOT reply to the replies, I'll summarize the results in a week's time and then we can discuss it further. Should we drop support for kernels 2.6.22 in our v4l-dvb repository? X _: Yes _: No Optional question: Why: After a certain point it becomes in practical terms impossible to support old versions of anything. There are too many dependencies on too many things that have to be changed all at once. The resulting problems do not pertain only to kernel-related development but to all development, as I have tried to make clear in other posts. I do not know the gory details of just what has become too difficult, as I am new to this area of kernel development, but I am quite willing, based upon a general description, and based upon other experience, to believe that there are problems. I think it is obvious that a version cutoff has to be made somewhere, and seven minor versions behind the kernel which is about to come out does not at all appear to me to be an unreasonable restriction. -- 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] How to pass camera Orientation to userspace
On Sunday 22 February 2009 23:54:42 Hans de Goede wrote: Trent Piepho wrote: On Sun, 22 Feb 2009, Hans de Goede wrote: Yes that is what we are talking about, the camera having a gravity switch (usually nothing as advanced as a gyroscope). Also the bits we are talking about are in a struct which communicates information one way, from the camera to userspace, so there is no way to clear the bits to make the camera do something. First, I'd like to say I agree with most that the installed orientation of the camera sensor really is a different concept than the current value of a gravity sensor. It's not necessary, and maybe not even desirable, to handle them in the same way. I do not see the advantage of using reserved bits instead of controls. The are a limited number of reserved bits. In some structures there are only a few left. They will run out. Then what? Packing non-standard sensor attributes and camera sensor meta-data into a few reserved bits is not a sustainable policy. Controls on the other card are not limited and won't run out. Yes but these things are *not* controls, end of discussion. The control API is for controls, not to stuff all kind of cruft in. I agree, these are not controls. There is an option to use the current status field. There are enough bits free, that's not the problem. But the spec is explicit about the fact that these bits apply to the current input only, and that's not true for these new bits. We can change the spec in this regard of course, but then you have to document each bit of the status field whether it is valid for the current input only, or also if this isn't the current input. It's all a bit messy. In addition, there are 4 reserved fields here and it is the first time in a very long time that we actually need one. And after all, that's why they are there in the first place. I see three options: 1) stuff them into the status field after all. 2) take one of the reserved fields and make it a single 'flags' field. 3) take one of the reserved fields and make it a u16 capabilities and u16 flags field. Trent does have a point that we need to be careful not to add fields without a good reason. Choosing option 1 fits the bill, and the orientation also fits the 'status' name. Only the sensor mount orientation is not really a status. Although with some creative naming we might come close :-) Hmm, let's see: V4L2_IN_ST_HAS_SENSOR_INFO 0x0010 V4L2_IN_ST_SENSOR_HFLIPPED 0x0020 V4L2_IN_ST_SENSOR_VFLIPPED 0x0040 V4L2_IN_ST_HAS_PIVOT_INFO 0x1000 V4L2_IN_ST_PIVOT_0 0x V4L2_IN_ST_PIVOT_90 0x2000 V4L2_IN_ST_PIVOT_1800x4000 V4L2_IN_ST_PIVOT_2700x6000 V4L2_IN_ST_PIVOT_MSK0x6000 Actually, that's not too bad. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: struct dvb_frontend not initialized correctly / random id value since MFE merge
Hi Matthias,
Matthias Schwarzott wrote:
MFE patches added a variable id to struct dvb_frontend.
This variable seems to be uninitialized for some drivers.
The result is for my skystar2 card (using stv0299 frontend) it sometimes is 0
as it should but sometimes it is a random value, so I get this register
message:
DVB: registering adapter 1 frontend -10551321 (ST STV0299 DVB-S)
The related kernel thread then also has a strange name like:
kdvb-ad-1-fe--1
I just noticed the same bug (with tda1004x). I think fe-id isn't
useful to dvb_frontend.c and should be removed. It is used where
fepriv-dvbdev-id should be used instead. Bridge drivers could
probably store this id elsewhere, if they need it.
The same happens for my dvb-ttpci card using ves1x93 frontend.
Now I wonder if all frontend drivers should be switched to use kzalloc
instead
of kmalloc for struct dvb_frontend
That's a good thing to do in any case.
How about the attached patch?
Regards,
Andreas
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 8434077..332dee3 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -216,9 +216,11 @@ static int dvb_frontend_get_event(struct dvb_frontend *fe,
static void dvb_frontend_init(struct dvb_frontend *fe)
{
- dprintk (DVB: initialising adapter %i frontend %i (%s)...\n,
+ struct dvb_frontend_private *fepriv = fe-frontend_priv;
+
+ dprintk (DVB%u: initialising frontend%i (%s)...\n,
fe-dvb-num,
- fe-id,
+ fepriv-dvbdev-id,
fe-ops.info.name);
if (fe-ops.init)
@@ -754,7 +756,7 @@ static int dvb_frontend_start(struct dvb_frontend *fe)
mb();
fe_thread = kthread_run(dvb_frontend_thread, fe,
- kdvb-ad-%i-fe-%i, fe-dvb-num,fe-id);
+ kdvb-ad-%i-fe-%i, fe-dvb-num,fepriv-dvbdev-id);
if (IS_ERR(fe_thread)) {
ret = PTR_ERR(fe_thread);
printk(dvb_frontend_start: failed to start kthread (%d)\n, ret);
@@ -768,6 +770,8 @@ static int dvb_frontend_start(struct dvb_frontend *fe)
static void dvb_frontend_get_frequeny_limits(struct dvb_frontend *fe,
u32 *freq_min, u32 *freq_max)
{
+ struct dvb_frontend_private *fepriv = fe-frontend_priv;
+
*freq_min = max(fe-ops.info.frequency_min, fe-ops.tuner_ops.info.frequency_min);
if (fe-ops.info.frequency_max == 0)
@@ -778,13 +782,14 @@ static void dvb_frontend_get_frequeny_limits(struct dvb_frontend *fe,
*freq_max = min(fe-ops.info.frequency_max, fe-ops.tuner_ops.info.frequency_max);
if (*freq_min == 0 || *freq_max == 0)
- printk(KERN_WARNING DVB: adapter %i frontend %u frequency limits undefined - fix the driver\n,
- fe-dvb-num,fe-id);
+ printk(KERN_WARNING DVB%u: frontend%u frequency limits undefined - fix the driver\n,
+ fe-dvb-num,fepriv-dvbdev-id);
}
static int dvb_frontend_check_parameters(struct dvb_frontend *fe,
struct dvb_frontend_parameters *parms)
{
+ struct dvb_frontend_private *fepriv = fe-frontend_priv;
u32 freq_min;
u32 freq_max;
@@ -792,8 +797,8 @@ static int dvb_frontend_check_parameters(struct dvb_frontend *fe,
dvb_frontend_get_frequeny_limits(fe, freq_min, freq_max);
if ((freq_min parms-frequency freq_min) ||
(freq_max parms-frequency freq_max)) {
- printk(KERN_WARNING DVB: adapter %i frontend %i frequency %u out of range (%u..%u)\n,
- fe-dvb-num, fe-id, parms-frequency, freq_min, freq_max);
+ printk(KERN_WARNING DVB%u: frontend%u frequency %u out of range (%u..%u)\n,
+ fe-dvb-num, fepriv-dvbdev-id, parms-frequency, freq_min, freq_max);
return -EINVAL;
}
@@ -803,8 +808,8 @@ static int dvb_frontend_check_parameters(struct dvb_frontend *fe,
parms-u.qpsk.symbol_rate fe-ops.info.symbol_rate_min) ||
(fe-ops.info.symbol_rate_max
parms-u.qpsk.symbol_rate fe-ops.info.symbol_rate_max)) {
- printk(KERN_WARNING DVB: adapter %i frontend %i symbol rate %u out of range (%u..%u)\n,
- fe-dvb-num, fe-id, parms-u.qpsk.symbol_rate,
+ printk(KERN_WARNING DVB%u: frontend%u symbol rate %u out of range (%u..%u)\n,
+ fe-dvb-num, fepriv-dvbdev-id, parms-u.qpsk.symbol_rate,
fe-ops.info.symbol_rate_min, fe-ops.info.symbol_rate_max);
return -EINVAL;
}
@@ -814,8 +819,8 @@ static int dvb_frontend_check_parameters(struct dvb_frontend *fe,
parms-u.qam.symbol_rate fe-ops.info.symbol_rate_min) ||
(fe-ops.info.symbol_rate_max
parms-u.qam.symbol_rate fe-ops.info.symbol_rate_max)) {
- printk(KERN_WARNING DVB: adapter %i frontend %i symbol rate %u out of range (%u..%u)\n,
- fe-dvb-num, fe-id, parms-u.qam.symbol_rate,
+ printk(KERN_WARNING DVB%u: frontend%u symbol rate %u out of range (%u..%u)\n,
+ fe-dvb-num, fepriv-dvbdev-id, parms-u.qam.symbol_rate,
fe-ops.info.symbol_rate_min, fe-ops.info.symbol_rate_max);
return -EINVAL;
}
@@ -1893,11 +1898,11 @@ int dvb_register_frontend(struct dvb_adapter* dvb,
.fops =
Re: POLL: for/against dropping support for kernels 2.6.22
On Sun, 2009-02-22 at 14:12 -0500, CityK wrote: The V4L-DVB is lacking in strategic direction. Yesterday was the time to adopt one; so lets pick up one today! CityK, I see you've been reading (or channeling) my blathering: http://www.linuxtv.org/irc/v4l/index.php?date=2009-02-20 ([19:42] to [20:21]) 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] How to pass camera Orientation to userspace
On Mon, 23 Feb 2009, Hans Verkuil wrote: On Sunday 22 February 2009 23:54:42 Hans de Goede wrote: Trent Piepho wrote: On Sun, 22 Feb 2009, Hans de Goede wrote: Yes that is what we are talking about, the camera having a gravity switch (usually nothing as advanced as a gyroscope). Also the bits we are talking about are in a struct which communicates information one way, from the camera to userspace, so there is no way to clear the bits to make the camera do something. First, I'd like to say I agree with most that the installed orientation of the camera sensor really is a different concept than the current value of a gravity sensor. It's not necessary, and maybe not even desirable, to handle them in the same way. I do not see the advantage of using reserved bits instead of controls. The are a limited number of reserved bits. In some structures there are only a few left. They will run out. Then what? Packing non-standard sensor attributes and camera sensor meta-data into a few reserved bits is not a sustainable policy. Controls on the other card are not limited and won't run out. Yes but these things are *not* controls, end of discussion. The control API is for controls, not to stuff all kind of cruft in. I agree, these are not controls. There is an option to use the current status field. There are enough bits free, that's not the problem. But the spec is explicit about the fact that these bits apply to the current input only, and that's not true for these new bits. We can change the spec in this regard of course, but then you have to document each bit of the status field whether it is valid for the current input only, or also if this isn't the current input. It's all a bit messy. In addition, there are 4 reserved fields here and it is the first time in a very long time that we actually need one. And after all, that's why they are there in the first place. v4l2_capability: 5 of 32 cap bits left, 4 reserved words v4l2_fmtdesc: 31 flag bits, 4 reserved words v4l2_buffer: 22 flags bits, 1 reserved word v4l2_framebuffer: 25 cap bits, 26 flag bits, no reserved words v4l2_input: 4 reserved words v4l2_output: 4 reserved words v4l2_tuner: 27 cap bits, 4 reserved words Trent does have a point that we need to be careful not to add fields without a good reason. Choosing option 1 fits the bill, and the orientation also fits the 'status' name. Only the sensor mount orientation is not really a status. Although with some creative naming we might come close :-) Hmm, let's see: V4L2_IN_ST_HAS_SENSOR_INFO0x0010 V4L2_IN_ST_SENSOR_HFLIPPED0x0020 V4L2_IN_ST_SENSOR_VFLIPPED0x0040 V4L2_IN_ST_HAS_PIVOT_INFO 0x1000 V4L2_IN_ST_PIVOT_00x V4L2_IN_ST_PIVOT_90 0x2000 V4L2_IN_ST_PIVOT_180 0x4000 V4L2_IN_ST_PIVOT_270 0x6000 V4L2_IN_ST_PIVOT_MSK 0x6000 One of my other points what the controls include meta-data. What happens when someone has an orientation sensor with 45 degree resolution? A control would just change the step size from 90 to 45. Existing software would already know what it means. With this method you have to add: V4L2_IN_ST_HAS_PIVOT_45_INFO0x8000 V4L2_IN_ST_PIVOT_45 0x0001 V4L2_IN_ST_PIVOT_1350x00012000 V4L2_IN_ST_PIVOT_2250x00014000 V4L2_IN_ST_PIVOT_3150x00016000 V4L2_IN_ST_PIVOT_45_MSK 0x00016000 Interpreting the pivot bits becomes more fun now. Existing software can do nothing with these extra bits. It can tell the user nothing. Next, add camera aperture. f/0.7 to f/64 in both half stop and third stop increments. Getting low on bits already. Suppose I have just three or four sensors on my camera. That's not all that much. A typical digital camera has more than that. They're probably connected by something slow, like I2C. Maybe non-trivial calculations are needed to use the data, like most demod's SNR registers. Each time I query the input the driver must query and calculate the value of ALL the sensors. Even though I only can about one of them. Controls can be queried individually. -- 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] How to pass camera Orientation to userspace
On Mon, 23 Feb 2009, Hans de Goede wrote: Trent Piepho wrote: On Sun, 22 Feb 2009, Hans de Goede wrote: Trent Piepho wrote: On Sun, 22 Feb 2009, Hans de Goede wrote: Yes that is what we are talking about, the camera having a gravity switch (usually nothing as advanced as a gyroscope). Also the bits we are talking about are in a struct which communicates information one way, from the camera to userspace, so there is no way to clear the bits to make the camera do something. First, I'd like to say I agree with most that the installed orientation of the camera sensor really is a different concept than the current value of a gravity sensor. It's not necessary, and maybe not even desirable, to handle them in the same way. I do not see the advantage of using reserved bits instead of controls. The are a limited number of reserved bits. In some structures there are only a few left. They will run out. Then what? Packing non-standard sensor attributes and camera sensor meta-data into a few reserved bits is not a sustainable policy. Controls on the other card are not limited and won't run out. Yes but these things are *not* controls, end of discussion. The control API is for controls, not to stuff all kind of cruft in. All kind of cruft belongs in the reserved bits of whatever field it can be stuffed in? Not whatever field, these are input properties which happen to also be pretty binary so putting them in the input flags field makes plenty of sense. What is the difference? Why does it matter? Performance? Maintenance? Is there something that's not possible? I do not find end of discussion to be a very convincing argument. Well they are not controls, that is the difference, the control interface is for controls (and only for controls, end of discussion if you ask me). These are not controls but properties, they do not have a default min and max value, Camera pivot sensor ranges from 0 to 270. How is that not a min and max? they have only one *unchanging* value, there is nothing the application can Camera sensors don't have an unchanging value. And who says scan order can't change? Suppose the camera returns raw bayer format data top to bottom, but if you request yuv then an image processing section needs to kick in and that returns the data bottom to top. control / change. It has been suggested to make them readonly, but that does not fix the ugliness. A proper written v4l2 application will enumerate all the controls, and then the user will see a grayed out control saying: your cam is upside down what is there to control ? will this be a grayed out slider? or a grayed out checkbox your cam is upside down, or maybe a not grayed out dropdown: where the user can select: my sensor is upside down, I deny my sensor is upside down, I don't care my sensor is upside down, WTF is this doing in my webcam control panel?, nwod edispu si rosnes yM Why is there a read-only flag for controls if the concept is so mind blowing to users? Have there been complaints about it? Do you know I have an idea, lets get rid of the S2 API for DVB and put all that in controls too. Oh, and think like standards for video formats, surely that can be a control too, and ... and, ... Good point. The S2 API is much more like the control interface than the previous API. Enumerated attributes which can be set one at a time or in groups. More can be added. There is some meta data about them. The old API used the a limited number of fixed structs, a few reserved bits, no meta-data, and a query/set everything at once API. I think the camera meta-data and camera sensor API should look more like S2. -- 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: POLL: for/against dropping support for kernels 2.6.22
Am Sonntag, den 22.02.2009, 11:15 +0100 schrieb Hans Verkuil: Hi all, There are lot's of discussions, but it can be hard sometimes to actually determine someone's opinion. So here is a quick poll, please reply either to the list or directly to me with your yes/no answer and (optional but welcome) a short explanation to your standpoint. It doesn't matter if you are a user or developer, I'd like to see your opinion regardless. Please DO NOT reply to the replies, I'll summarize the results in a week's time and then we can discuss it further. Should we drop support for kernels 2.6.22 in our v4l-dvb repository? _: Yes _: No Yes. Optional question: Why: Keeping too old kernels supported makes others lazy and in worst case they ask you to support v4l2 version one. (happened) Our user base for new devices is covered with down to 2.6.22 for now, we likely never got anything from those on old commercial distribution kernels, same for Debian and stuff derived from there. Since new drivers actually prefer to avoid the compat work and are happy to make it just into the latest rc1 during the merge window and further from there, there is no loss either. Some new devices we likely get on already established drivers should not be hard to add to a v4l-dvb tar ball we leave with support for the even older kernels. Cheers, Hermann -- 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 2/2 v2] soc-camera: configure drivers with a default format on open
Dear Guennadi Currently soc-camera doesn't set up any image format without an explicit S_FMT. It seems this should be supported, since, for example, capture-example.c from v4l2-apps by default doesn't issue an S_FMT. This patch configures a default image format on open(). (snip) Ok, you're right. I do call it now. How about this version? Thank you for hard work. but... It doesn't work either in same reason. I'm not sure for detail. but meybe there is a problem in the call order. ov772x_try_fmt is called when soc_camera_open is called. but sh_mobile_ceu_init_videobuf that set filed to ANY is called after soc_camera_open. And ov772x_try_fmt should be called after sh_mobile_ceu_init_videobuf. Best regards -- Kuninori Morimoto -- 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: POLL: for/against dropping support for kernels 2.6.22
Yes... On Mon Feb 23 12:13 , hermann pitton sent: Am Sonntag, den 22.02.2009, 11:15 +0100 schrieb Hans Verkuil: Hi all, There are lot's of discussions, but it can be hard sometimes to actually determine someone's opinion. So here is a quick poll, please reply either to the list or directly to me with your yes/no answer and (optional but welcome) a short explanation to your standpoint. It doesn't matter if you are a user or developer, I'd like to see your opinion regardless. Please DO NOT reply to the replies, I'll summarize the results in a week's time and then we can discuss it further. Should we drop support for kernels _: Yes _: No Yes. Optional question: Why: Keeping too old kernels supported makes others lazy and in worst case they ask you to support v4l2 version one. (happened) Our user base for new devices is covered with down to 2.6.22 for now, we likely never got anything from those on old commercial distribution kernels, same for Debian and stuff derived from there. Since new drivers actually prefer to avoid the compat work and are happy to make it just into the latest rc1 during the merge window and further from there, there is no loss either. Some new devices we likely get on already established drivers should not be hard to add to a v4l-dvb tar ball we leave with support for the even older kernels. Cheers, Hermann -- 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 Sony PlayTV to dibcom driver
On Sun, 22 Feb 2009 15:04:13 -0500 CityK ci...@rogers.com wrote: I don't think the Patchwork tool picked it up, as I don't see it in the queue :( http://patchwork.kernel.org/project/linux-media/list/ I'm wondering it the quotations in the subject line are enough to throw the script off. Mauro, any ideas? In general those tools to pick and work with scripts don't like very much inlined patches, although it generally works. Also, it requires that the patch is not line wrapped. In this specific case, the patch is line-wrapped: --- v4l-dvb-359d95e1d541-vanilla/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2009-02-18 13:49:37.0 +0100 +++ v4l-dvb-359d95e1d541/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2009-02-18 23:45:43.0 +0100 instead of: --- v4l-dvb-359d95e1d541-vanilla/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2009-02-18 13:49:37.0 +0100 +++ v4l-dvb-359d95e1d541/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2009-02-18 23:45:43.0 +0100 So, it doesn't apply as a patch and patchwork discards it. Sebastian, could you please send it again, being sure that your email won't break long lines? 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: [Bulk] Re: POLL: for/against dropping support for kernels 2.6.22
Andy Walls wrote: On Sun, 2009-02-22 at 14:12 -0500, CityK wrote: The V4L-DVB is lacking in strategic direction. Yesterday was the time to adopt one; so lets pick up one today! CityK, I see you've been reading (or channeling) my blathering: http://www.linuxtv.org/irc/v4l/index.php?date=2009-02-20 ([19:42] to [20:21]) Regards, Andy Rabble Rabble Rabble! ( http://www.urbandictionary.com/define.php?term=RABBLE RABBLE RABBLE! ) -- 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 Sony PlayTV to dibcom driver
Mauro Carvalho Chehab wrote: On Sun, 22 Feb 2009 15:04:13 -0500 CityK ci...@rogers.com wrote: I don't think the Patchwork tool picked it up, as I don't see it in the queue :( http://patchwork.kernel.org/project/linux-media/list/ I'm wondering it the quotations in the subject line are enough to throw the script off. Mauro, any ideas? In general those tools to pick and work with scripts don't like very much inlined patches, although it generally works. Also, it requires that the patch is not line wrapped. In this specific case, the patch is line-wrapped: --- v4l-dvb-359d95e1d541-vanilla/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2009-02-18 13:49:37.0 +0100 +++ v4l-dvb-359d95e1d541/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2009-02-18 23:45:43.0 +0100 instead of: --- v4l-dvb-359d95e1d541-vanilla/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2009-02-18 13:49:37.0 +0100 +++ v4l-dvb-359d95e1d541/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2009-02-18 23:45:43.0 +0100 So, it doesn't apply as a patch and patchwork discards it. Ahh, thanks for the explanation. Its strange that they are not tailored for inline patches, given that that is precisely the preferred and prescribed submission method! -- 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
About the specific setting for lens
Dear Guennadi.
Now MigoR and AP325 board have ov772x camera.
However, the lens used is different.
And I have a specific good setting value
for the lens of AP325.
So, I would like to add new function for
specific lens value.
meybe like this.
Can I add it ?
-- board-ap325 ---
static const struct regval_list ov772x_lens[] = {
{ 0xAA, 0xBB }, { 0xCC, 0xDD }, { 0xEE, 0xFF },
...
ENDMARKER,
}
static struct ov772x_camera_info ov772x_info = {
...
.lenssetting = ov772x_lens,
}
-
--- ov772x.c
static int ov772x_start_capture(xxx)
{
...
if (priv-info-lenssetting) {
ret = ov772x_write_array(priv-client,
priv-info-lenssetting);
if (ret 0)
goto error;
}
...
}
-
Best regards
--
Kuninori Morimoto
--
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: POLL: for/against dropping support for kernels 2.6.22
2009/2/22 Hans Verkuil hverk...@xs4all.nl: Hi all, There are lot's of discussions, but it can be hard sometimes to actually determine someone's opinion. So here is a quick poll, please reply either to the list or directly to me with your yes/no answer and (optional but welcome) a short explanation to your standpoint. It doesn't matter if you are a user or developer, I'd like to see your opinion regardless. Please DO NOT reply to the replies, I'll summarize the results in a week's time and then we can discuss it further. Should we drop support for kernels 2.6.22 in our v4l-dvb repository? ** Yes ** _: No Optional question: Why: (from a non-coder, I have failed miserably to learn how to code in anything other than shell scripting) I think the development of later drivers suffers because of the work needed for backwards kernel compatibility. In any case, I think most home users (like me) will usually be very up to date with their kernels (we so like to tinker where we can) so the drivers for older kernels would only be of any use to those using enterprise kernels, and I think those should be addressed by the people being paid! Isn't that what they're being paid for? Thanks, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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 -- Regards,Robert . Some people can tell what time it is by looking at the sun, but I have never been able to make out the numbers. --- Errata: Spelling mistakes are not intentional, however, I don't use spell checkers because it's too easy to allow the spell checker to make the decisions and use words that are out of context for that being written, i.e. their/there, your/you're, threw/through and even accept/except, not to mention foreign (I'm Australian) English spelling, i.e. colour/color, socks/sox, etc,. -- 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
