Re: [RFC] How to pass camera Orientation to userspace
Trent Piepho wrote: 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. Yes, because hardware designers like throwing away lots of transistors to memory so they are going to put memory in the controller to buffer an entire frame and then scan out the memory buffer in different order then the sensor gave them the data, so they cannot do FIFO, so they will actually need 2 frames of memory. If the sensor is soldered upside down on the PCB that is a very much unchanging value, and an input property if you ask me. So new proposal: use 2 bits in the input flags to indicate if the input is hardwired vflipped and/or hflipped. Create a new class of controls for querying possible changing camera properties like pivoting and aperture. 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: POLL: for/against dropping support for kernels 2.6.22
On Sun, Feb 22, 2009 at 2:15 AM, Hans Verkuil hverk...@xs4all.nl wrote: Should we drop support for kernels 2.6.22 in our v4l-dvb repository? _: Yes _: No Yes. Optional question: Why: The reasons already stated, those resources could be better used doing other things. Aside of that, of the devs/users how many people actually _need_ to remain on an old kernel. I could be wrong in my assumption that most people using old kernels are doing so simply by choice and not necessity. You want to maximize developer productivity and if that means some people will need to update their kernel, is that so horrible? -- 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
Haupauge Nova-T 500 2.6.28 regression dib0700
Hi, I have some difficulties with the Hauppauge Nova-T 500 and 2.6.28 kernels. Following USB errors appear with 2.6.28.4 every 100ms: Feb 15 02:46:03 golem [ 7720.876132] usb 2-1: events/3 timed out on ep1in len=0/6 Feb 15 02:46:03 golem [ 7720.976039] usb 2-1: events/3 timed out on ep1in len=0/6 Feb 15 02:46:03 golem [ 7721.076068] usb 2-1: events/3 timed out on ep1in len=0/6 The device is still useable but occasionally I see the same error with additional usb errors (iirc same kernel and config) Feb 17 20:33:17 golem [ 14.733031] ehci_hcd :01:06.2: reused qh 8800bf80d140 schedule Feb 17 20:33:17 golem [ 14.733040] usb 2-1: link qh64-0001/8800bf80d140 start 63 [2/0 us] Feb 17 20:33:17 golem [ 14.783035] usb 2-1: unlink qh64-0001/8800bf80d140 start 63 [2/0 us] Feb 17 20:33:17 golem [ 14.783107] usb 2-1: events/3 timed out on ep1in len=0/6 ... Feb 17 20:34:12 golem [ 128.130059] ehci_hcd :01:06.2: reused qh 8800bf80d140 schedule Feb 17 20:34:12 golem [ 128.130069] usb 2-1: link qh64-0001/8800bf80d140 start 63 [2/0 us] Feb 17 20:34:12 golem [ 128.131007] ehci_hcd :01:06.2: force halt; handhake c2050014 00 004000 - -110 ehci gives up and the device is unuseabe. This is still the case with 2.6.28.7. git bisect blames following change: | commit 99afb989b05b9fb1c7b3831ce4b7a000b214acdb | Author: Devin Heitmueller devin.heitmuel...@gmail.com | Date: Sat Nov 15 07:13:07 2008 -0300 | | V4L/DVB (9639): Make dib0700 remote control support work with firmware v1.20 2.6.28.x with DVB drivers from v4l-dvb hg works as expected bu I fail to see which changeset fixed it. If you have an idea I'll test it. Otherwise I'll bisect v4l-dvb hg. This should be fixed in 2.6.28-stable. Janne -- 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 23:32:36 -0500 CityK ci...@rogers.com wrote: 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! Ops! I mean the opposite. It is fine for inlined patch. mime patches may have troubles. In fact, patchwork supports mime types, provided that the emailer describe the attachment with the proper type (text/x-patch). It the mime is text/plain, it should work also. However, if the emailer sends it with a different type, the attachment will be discarded. 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
PULL request (once more)
Hi Mauro, can you please pull this very important bugfix patch from my repository (http://linuxtv.org/hg/~pb/v4l-dvb/) . - [PATCH] software IRQ watchdog for Flexcop B2C2 DVB PCI cards This one is high-priority and has to go to 2.6.29 for its release. In the meantime I rebuilt and cleaned up my repository so that only this patch is new. Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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 Sat, 21 Feb 2009 12:53:57 +0100 Hans Verkuil hverk...@xs4all.nl wrote: Hi Adam, Sorry for the late reply, it's been very busy. Me too. 1) Reuse the existing HFLIP and VFLIP controls, marking them as read-only Pros : No change needed to videodev2.h Cons: It is confusing to have controls that have a subtly different meaning if they are read only. Existing apps that support those controls might get confused. Would require polling to support the case of a camera being turned toward / away from the user while streaming. Reusing an existing control for a different meaning seems wrong. What happens when some cam has the capability of doing hardware flipping, and have the cam flipped? 2) Introduce a new orientation control (possibly in a new CAMERA_PROPERTIES class) Pros: libv4l can easily tell if the driver supports the control. Cons: It is really a property, not a control so calling it a control is wrong. Controls add lots of overhead in terms of driver code. Would require polling to support the case of a camera being turned toward / away from the user while streaming. I think this could be a good idea, but I agree with Hans Verkuil comments: since this is a characteristics for a given input, using a control here would mean that the driver will return it based on the selected input. Seems a little messy. Also, a mounted characteristics of the device, is not really a sensor, as Hans de Goede pointed. 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 don't think this is a good idea. The metadata at the frame polling is meant to return the stream info. We shouldn't mix sensor position here. 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. Analog tv does polling for signal strength, since userspace apps do mute and stops presenting video, if the signal is too weak. IMO, a similar mechanism should be used by pivoting. IMO, this would be better addressed as a property of v4l2_input. So, I think that (5) is better than (4). 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. 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 There is a case that we should think: at libv4l, we may need to override the default orientation, by a custom one. For example: Surveillance systems have cameras mounted on a fixed position. Depending on the camera, and the desired position, some cameras may needed to be mounted rotated (the same case also applies to some embedded hardware like ATM machines, where a webcam maybe mounted with 180 degrees, due to hardware constraints). Ok, this is nothing that kernel needs to handle, but, at userspace, we need to have a file where the user could edit and store the camera position, to override whatever we have in kernel. 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. Furthermore, it is only needed on devices that cannot do v/hflipping in
Re: [RFC] How to pass camera Orientation to userspace
On Mon, 23 Feb 2009 08:34:08 +0100 Hans Verkuil hverk...@xs4all.nl wrote: On Monday 23 February 2009 00:56:40 Trent Piepho wrote: 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. These bits deal exclusively with the sensor position and for the sole purpose of deciding whether the image has to be rotated in hard/software to get it the right-way up. In most cases this is limited to rotating 180 degrees, but omap has some memory management tricks to do the 90/270 degree cases as well. This is not the same as having a full positioning 2D or 3D system in a camera that can give you exact angles. I do not think that should be part of v4l2. There isn't anything that v4l2 can do with that. An application might use this information to setup special transformations to do such rotates, and if the hardware can do that then that would be part of an effects API or something like that. With non-90 degree angle you just run into a totally different set of problems that are definitely out-of-scope. We are trying to address 2 different situations using the same approach. After thinking more about it, I suspect that we need two separate approaches.
Re: TT 3650
Hi again! Concerning this card (TT 3650 CI) in combination with the non-repo-driver (suggested below): which tuner should I use? Is there a special one needed? Original-Nachricht Datum: Wed, 18 Feb 2009 10:33:53 +0100 Von: Jean-Francois Moine moin...@free.fr An: Andreas Kurz kurz.a...@gmx.at CC: linux-media@vger.kernel.org Betreff: Re: TT 3650 On Wed, 18 Feb 2009 10:22:17 +0100 Andreas Kurz kurz.a...@gmx.at wrote: Few days ago I was asking for help: I have bought the TT 3650 CI but even after installing the drivers (as suggested in the WIKI-How-To) no card shows up in Yast. Does that mean, the card is not supported? Should I do something else? Is there another How-To around? Hello Andreas, I have such a USB device. It works fine without any patch with the last version of Igor M. Liplianin's repository: http://mercurial.intuxication.org/hg/s2-liplianin/ Regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 -- 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: mercurial problems?
On Sun, 22 Feb 2009 11:58:13 +0100 Hans Verkuil hverk...@xs4all.nl wrote: 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. hg-menu is working here. Could you please check again? 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: mercurial problems?
On Sun, 22 Feb 2009 11:58:13 +0100 Hans Verkuil hverk...@xs4all.nl wrote: 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. hg-menu is working here. Could you please check again? Cheers, Mauro Johannes reported that there where harddisk problems and at the time the harddisk was undergoing an fsck, so it was read-only. Hence the problems I experienced. It's working now. 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: POLL: for/against dropping support for kernels 2.6.22
On Sun, 22 Feb 2009 11:15:01 +0100 Hans Verkuil hverk...@xs4all.nl 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 No. Optional question: Why: For a couple of reasons: 1) This will remove testers from our user database; 2) The current way of backporting is not scaling. Just dropping support for a random version is just postponing the question that we need to re-think about the way for backport; 3) This doesn't solve the development issues we have of not using -git. This causes lots of work when sending patches uptreaming, on when someone changes something upstream and a backport is needed. So, in practice, this won't solve any real problem. I'm right now working on another way of allowing backport that will better scale, and will allow developers to use -git, without losing backport for users. 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: POLL: for/against dropping support for kernels 2.6.22
Hi Hans, 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: The cost to preserve backwards compatibility for these old kernels is much too high compared to the remaining user-base. I can only repeat the points I have made in the past week: * Maintained distributions aimed at home users (Fedora, openSUSE) run kernels = 2.6.22 by now. * Enterprise-class distributions (RHEL, SLED) are not the right target for the v4l-dvb repository, so we don't care which kernels these are running. * Engineering time which is put into backwards compatibility would be better spent on improving the drivers upstream and adding support for new hardware faster. * v4l-dvb depends on subsystems which do evolve, and when these changes are too important (e.g. new i2c device driver binding model) backwards compatibility comes are an unbearable complexity and cost. That kind of cost sucks the time of current developers, might turn them into ex-developers when they realize they lost all the fun, and prevents new developers from joining the project because of the complexity of the compatibility layer. So let's just drop support for kernels 2.6.22 and focus on better supporting upstream and recent kernels. 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
Re: POLL: for/against dropping support for kernels 2.6.22
On Mon, 23 Feb 2009, Jean Delvare wrote: 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? Does this mean keep our current system and move the backward compatibility point to 2.6.22? Or not have any backward compatibilty at all? -- 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 2033, Mantis
Any CAM support on this board today or planned ? Are willing to try bleeding edge code and provide feedback. 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: POLL: for/against dropping support for kernels 2.6.22
Hello Hans, On Sun, 22 Feb 2009 11:15:01 +0100 Hans Verkuil hverk...@xs4all.nl 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 No Optional question: Why: I know it's not easy task keep this support working... but we still have *users* around the world using kernel 2.6.22 (as some of them already reported this). Cheers, Douglas -- 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, Feb 22, 2009 at 5:15 AM, Hans Verkuil hverk...@xs4all.nl 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 can't we drop support for all but the latest kernel? Why: As others have already pointed out, it is a waste of time for developers who volunteer their time to work on supporting prior kernel revisions for use by enterprise distributions. The task of back-porting driver modifications to earlier kernels lessens the amount of time developers can focus on improving the quality and stability of new and existing drivers. Furthermore, it deters driver development since there an expectation that they will back-port their driver to earlier kernel versions. Finally, as a developer, I have have little interest in what was new yesterday. I usually run the latest kernel whenever possible and for a number of different reasons. Some of those reasons include better hardware support, bug detection, and stability testing. All services greatly valued by other kernel developers. Regards, David Ellingsworth -- 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 Mon, 23 Feb 2009 09:26:57 -0300 Mauro Carvalho Chehab mche...@infradead.org wrote: I'm right now working on another way of allowing backport that will better scale, and will allow developers to use -git, without losing backport for users. I have an incomplete skeleton for the backport scripts, available at: http://linuxtv.org/hg/~mchehab/backport For now, it is very dumb (it recompiles all drivers every time) and requires much more hacking to cleanup the Makefiles. The current version just removes a very simple check for linux version, but it is not hard to use this way for all cases where backport is needed. After having this working fine and supporting all backports, people can develop using -git as basis for development, without needing to take care of backport anymore. 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
[PATCH] remove redundant memset after kzalloc
Hi there!
While having a look at the allocation of struct dvb_frontend in *_attach
functions, I found some cases calling memset after kzalloc. This is
redundant, and the attached patch removes these calls.
I also changed one case calling kmalloc and memset to kzalloc.
Signed-off-by: Matthias Schwarzott z...@gentoo.org
Regards
Matthias
Index: v4l-dvb/linux/drivers/media/dvb/frontends/cx24113.c
===
--- v4l-dvb.orig/linux/drivers/media/dvb/frontends/cx24113.c
+++ v4l-dvb/linux/drivers/media/dvb/frontends/cx24113.c
@@ -559,7 +559,7 @@ struct dvb_frontend *cx24113_attach(stru
kzalloc(sizeof(struct cx24113_state), GFP_KERNEL);
int rc;
if (state == NULL) {
- err(Unable to kmalloc\n);
+ err(Unable to kzalloc\n);
goto error;
}
Index: v4l-dvb/linux/drivers/media/dvb/frontends/cx24116.c
===
--- v4l-dvb.orig/linux/drivers/media/dvb/frontends/cx24116.c
+++ v4l-dvb/linux/drivers/media/dvb/frontends/cx24116.c
@@ -1112,13 +1112,10 @@ struct dvb_frontend *cx24116_attach(cons
dprintk(%s\n, __func__);
/* allocate memory for the internal state */
- state = kmalloc(sizeof(struct cx24116_state), GFP_KERNEL);
+ state = kzalloc(sizeof(struct cx24116_state), GFP_KERNEL);
if (state == NULL)
goto error1;
- /* setup the state */
- memset(state, 0, sizeof(struct cx24116_state));
-
state-config = config;
state-i2c = i2c;
Index: v4l-dvb/linux/drivers/media/dvb/frontends/cx24123.c
===
--- v4l-dvb.orig/linux/drivers/media/dvb/frontends/cx24123.c
+++ v4l-dvb/linux/drivers/media/dvb/frontends/cx24123.c
@@ -1084,13 +1084,13 @@ static struct dvb_frontend_ops cx24123_o
struct dvb_frontend *cx24123_attach(const struct cx24123_config *config,
struct i2c_adapter *i2c)
{
+ /* allocate memory for the internal state */
struct cx24123_state *state =
kzalloc(sizeof(struct cx24123_state), GFP_KERNEL);
dprintk(\n);
- /* allocate memory for the internal state */
if (state == NULL) {
- err(Unable to kmalloc\n);
+ err(Unable to kzalloc\n);
goto error;
}
Index: v4l-dvb/linux/drivers/media/dvb/frontends/lgdt3304.c
===
--- v4l-dvb.orig/linux/drivers/media/dvb/frontends/lgdt3304.c
+++ v4l-dvb/linux/drivers/media/dvb/frontends/lgdt3304.c
@@ -383,7 +383,6 @@ struct dvb_frontend* lgdt3304_attach(con
struct lgdt3304_state *state;
state = kzalloc(sizeof(struct lgdt3304_state), GFP_KERNEL);
- memset(state, 0x0, sizeof(struct lgdt3304_state));
state-addr = config-i2c_address;
state-i2c = i2c;
Index: v4l-dvb/linux/drivers/media/dvb/frontends/s921_module.c
===
--- v4l-dvb.orig/linux/drivers/media/dvb/frontends/s921_module.c
+++ v4l-dvb/linux/drivers/media/dvb/frontends/s921_module.c
@@ -233,7 +233,6 @@ struct dvb_frontend* s921_attach(const s
struct s921_state *state;
state = kzalloc(sizeof(struct s921_state), GFP_KERNEL);
- memset(state, 0x0, sizeof(struct s921_state));
state-addr = config-i2c_address;
state-i2c = i2c;
Re: Haupauge Nova-T 500 2.6.28 regression dib0700
On Mon, Feb 23, 2009 at 4:52 AM, Janne Grunau j...@jannau.net wrote: Hi, I have some difficulties with the Hauppauge Nova-T 500 and 2.6.28 kernels. Following USB errors appear with 2.6.28.4 every 100ms: Feb 15 02:46:03 golem [ 7720.876132] usb 2-1: events/3 timed out on ep1in len=0/6 Feb 15 02:46:03 golem [ 7720.976039] usb 2-1: events/3 timed out on ep1in len=0/6 Feb 15 02:46:03 golem [ 7721.076068] usb 2-1: events/3 timed out on ep1in len=0/6 The device is still useable but occasionally I see the same error with additional usb errors (iirc same kernel and config) Feb 17 20:33:17 golem [ 14.733031] ehci_hcd :01:06.2: reused qh 8800bf80d140 schedule Feb 17 20:33:17 golem [ 14.733040] usb 2-1: link qh64-0001/8800bf80d140 start 63 [2/0 us] Feb 17 20:33:17 golem [ 14.783035] usb 2-1: unlink qh64-0001/8800bf80d140 start 63 [2/0 us] Feb 17 20:33:17 golem [ 14.783107] usb 2-1: events/3 timed out on ep1in len=0/6 ... Feb 17 20:34:12 golem [ 128.130059] ehci_hcd :01:06.2: reused qh 8800bf80d140 schedule Feb 17 20:34:12 golem [ 128.130069] usb 2-1: link qh64-0001/8800bf80d140 start 63 [2/0 us] Feb 17 20:34:12 golem [ 128.131007] ehci_hcd :01:06.2: force halt; handhake c2050014 00 004000 - -110 ehci gives up and the device is unuseabe. This is still the case with 2.6.28.7. git bisect blames following change: | commit 99afb989b05b9fb1c7b3831ce4b7a000b214acdb | Author: Devin Heitmueller devin.heitmuel...@gmail.com | Date: Sat Nov 15 07:13:07 2008 -0300 | | V4L/DVB (9639): Make dib0700 remote control support work with firmware v1.20 2.6.28.x with DVB drivers from v4l-dvb hg works as expected bu I fail to see which changeset fixed it. If you have an idea I'll test it. Otherwise I'll bisect v4l-dvb hg. This should be fixed in 2.6.28-stable. Janne Hello Janneg, Thank you for reporting this issue. We actually rely on the bulk endpoint timing out to query the IR port if there is no keypress. I wonder if they introduced a new kernel warning in 2.6.28.4 when this occurs. Regarding the other issue, is there any correlation with the errors to plugging/unplugging the devices? Perhaps there is an issue with cancellation of the thread that does the polling when the device is disconnected. I actually don't have a Nova-T 500. I did all the development on the dib0700 based Pinnacle 801e. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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
Question regarding detail in dropping support for kernels 2.6.22 (related to Re: POLL: for/against dropping support for kernels 2.6.22)
Hello Hans, Hans Verkuil schrieb: We still need to support kernels from 2.6.22 onwards. Although I think the minimum supported kernel is something that needs a regular sanity check, right now there are no technical reasons that I am aware of to go to something newer than 2.6.22. Whether we keep our current system or not is a separate discussion: whatever development system you choose there will be work involved in keeping up the backwards compatibility. Just out of deep interesst: Could you, Hans (or anyone else) just explain, what is / are the reason to draw the line between kernels 2.6.21 and 2.6.22? What was the fundamental change there and do these changes as such apply to every supported device / driver? As I understand you, although you drop backport efforts for kernels below 2.6.22, you are going to adopt an policy to - in a sense - waste development efforts / time on seven instead of 12 kernels? Wouldn't it then not be more logical to support only the recent kernel and the kernel before, becaus in some month time 2.6.30 might include a major change which would force you to drop support for 2.6.29 altogether? Thanks for your patience and reply, best regards, Tobias -- 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: Question regarding detail in dropping support for kernels 2.6.22 (related to Re: POLL: for/against dropping support for kernels 2.6.22)
Hello Hans, Hans Verkuil schrieb: We still need to support kernels from 2.6.22 onwards. Although I think the minimum supported kernel is something that needs a regular sanity check, right now there are no technical reasons that I am aware of to go to something newer than 2.6.22. Whether we keep our current system or not is a separate discussion: whatever development system you choose there will be work involved in keeping up the backwards compatibility. Just out of deep interesst: Could you, Hans (or anyone else) just explain, what is / are the reason to draw the line between kernels 2.6.21 and 2.6.22? What was the fundamental change there and do these changes as such apply to every supported device / driver? As I understand you, although you drop backport efforts for kernels below 2.6.22, you are going to adopt an policy to - in a sense - waste development efforts / time on seven instead of 12 kernels? Wouldn't it then not be more logical to support only the recent kernel and the kernel before, becaus in some month time 2.6.30 might include a major change which would force you to drop support for 2.6.29 altogether? Thanks for your patience and reply, Hi Tobias, No problem, I'd be happy to explain. For a long time whenever you loaded an i2c module the kernel i2c core would probe all i2c adapters to see if a chip supported by the i2c module was present. This is very, very bad since the act of probing can corrupt eeproms and worse. In addition, since many i2c devices cannot be properly identified, you often get misdetections where the driver thinks it found a match, when in reality it was a different device altogether. In kernel 2.6.22 a new i2c API was created that allowed the adapter driver such as bttv or ivtv to tell the i2c core what i2c devices are on which address. So a driver that supported the new i2c API would prevent i2c modules from autoprobing its i2c adapters, and it has to explicitly tell the i2c code what device is where. It's a bit simplified since there are still some probing methods available, but in all cases it is the adapter driver that initiates them. This is a huge improvement and solves many problems that were previously unsolvable. But it is a totally different approach where the i2c module no longer initiates probes, but instead it is done by the adapter driver. However, it is a big task to convert drivers from the old to the new API. It requires modifying the i2c modules to support the new API, but as long as such modules are also still in use by unconverted adapter drivers they have to support the old API as well. And before you can convert an adapter driver *all* i2c modules it uses need to be converted to support the new API. In addition, since kernels older than 2.6.22 do not support the new API at all, we need to keep support for the old API around under #if KERNEL_VERSION as well. To make all this possible without creating i2c modules riddled with #if's I created two headers that hide most of this complexity. However, these headers are exposed in the upstream kernel where they look really weird when they are stripped from all #ifs. Now all this is fine as long as adapter drivers exist that are not yet converted, since that means we need to keep the compat stuff around anyway. But I'm now attempting to finally convert the last drivers, hopefully before the 2.6.30 merge window will close. Once that is done, the only reason left to keep the compat code around is to support pre-2.6.22 kernels. It's a lot of tricky code meant primarily to support the transition from the old to new i2c API. Now that we have almost finished this transition I think it is time to say goodbye to all the code needed to keep the old i2c API alive. And that means effectively dropping support for kernels older than 2.6.22. Of course, I might not be able to finish the conversion in time for 2.6.30, in which case the compat code needs to stay around for another kernel cycle. Luckily, such major API redesigns are rare. And normally the effort needed to keep compatibility is fairly limited and the additional test exposure is very welcome. So there are good reasons for having backwards compatibility. I didn't create the daily build system to verify that it still compiles on older kernels for nothing. But there are limits to the amount of effort that I am willing to spend on it. And in this case I think it's time to drop the compatibility with the old i2c API entirely. A long and technical story, but I hope it helps explain the background. 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: PVR x50 corrupts ATSC 115 streams
On Sun, Feb 22, 2009 at 02:35:00PM -0500, CityK wrote: 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. I've used 2.6.27.17 in most my testing, either with stock drivers or with drivers from Mercurial. I tried 2.6.26, .25 and .24 on Saturday, but it made no difference. After seeing this message, I tried 2.6.22 and .21 yesterday (Sunday). Again, it made no difference. I think the ATSC 115s are just going to always report at least some level of BER. Anyway, here are the other results of more testing over the weekend. I tried an ATSC 115 with a PVR 250 in my desktop system. Like with my MythTV backend, the 115 digital recordings were slightly corrupted when the x50 was active. The corruption appeared to be a little less frequent, though. Instead of some corruption occuring every couple of seconds, it was more like every 4 or 5 seconds. Both my desktop and current MythTV backend are AMD systems with Nvidia chipsets. My old backend, which didn't exhibit the corruption problem, was a P4 system with an Intel chipset. I can't get any 115 to work in my current backend without an x50 installed and connected to cable. I tried a single 115 is every slot. I tried older kernels. I tried multiple 115s in combinations. I tried a 115 with an Audigy sound card I had. In every case, the 115 reports excessive BER and UNC and capture of any digital stream is almost impossible. The 115s will behave this way until I install at least one x50 card and connect it the cable. I even tried the same 115 I had used not more than a month ago with the same motherboard and graphics card as my desktop. Only the case, power suuply and disks are now different. Could there be some kind of short on the motherboard or case that could case this behavior? I remembered I had a DVICO FusionHDTV5 lying around. I don't use that card much because, in my past experience, the cx88 driver doesn't play as well with the ivtv driver as the saa7134 driver. See below for an example (*). The HDTV5 does report 0 for bER: status SCVYL | signal fd43 | snr 22a0 | ber | unc | FE_HAS_LOCK status SCVYL | signal fcde | snr 2292 | ber | unc | FE_HAS_LOCK status SCVYL | signal fd87 | snr 22b7 | ber | unc | FE_HAS_LOCK status SCVYL | signal fd65 | snr 22a4 | ber | unc | FE_HAS_LOCK status SCVYL | signal fd65 | snr 22a4 | ber | unc | FE_HAS_LOCK status SCVYL | signal fd43 | snr 2292 | ber | unc | FE_HAS_LOCK status SCVYL | signal fda9 | snr 22c5 | ber | unc | FE_HAS_LOCK status SCVYL | signal fe34 | snr 22c1 | ber | unc | FE_HAS_LOCK status SCVYL | signal fe11 | snr 22bc | ber | unc | FE_HAS_LOCK status SCVYL | signal fda9 | snr 22a0 | ber | unc | FE_HAS_LOCK In addition, the HDTV5 does not have any corruption when the x50s are active. I ran one test with the HDTV5, one 115 and two x50s. The HDTV5 didn't show corruption while the 115 did. To be sure it wasn't the content, I stopped the digital recordings and restarted them so the cards would be swapped. The corruption stayed with the 115. To summarize, I have two problems. First, the 115s show corruption when an x50 is active. This occurs on two differnt systems with Nvidia chipsets, but did not occur in a system with an Intel chipset. An HDTV in the same system does not show the corruption problem. Second, the 115s apparently can't receive a clean signal unless theer is a x50 installed and connected. (*) About half the time I boot with the HDTV5 and x50 cards, the x50 tuners don't work. The x50s will only record static until I manually unload and reload the tuner modules. David -- David Engel da...@istwok.net -- 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: On Sun, Feb 22, 2009 at 02:35:00PM -0500, CityK wrote: 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. I've used 2.6.27.17 in most my testing, either with stock drivers or with drivers from Mercurial. I tried 2.6.26, .25 and .24 on Saturday, but it made no difference. After seeing this message, I tried 2.6.22 and .21 yesterday (Sunday). Again, it made no difference. I think the ATSC 115s are just going to always report at least some level of BER. Anyway, here are the other results of more testing over the weekend. I tried an ATSC 115 with a PVR 250 in my desktop system. Like with my MythTV backend, the 115 digital recordings were slightly corrupted when the x50 was active. The corruption appeared to be a little less frequent, though. Instead of some corruption occuring every couple of seconds, it was more like every 4 or 5 seconds. Both my desktop and current MythTV backend are AMD systems with Nvidia chipsets. My old backend, which didn't exhibit the corruption problem, was a P4 system with an Intel chipset. I can't get any 115 to work in my current backend without an x50 installed and connected to cable. I tried a single 115 is every slot. I tried older kernels. I tried multiple 115s in combinations. I tried a 115 with an Audigy sound card I had. In every case, the 115 reports excessive BER and UNC and capture of any digital stream is almost impossible. The 115s will behave this way until I install at least one x50 card and connect it the cable. I even tried the same 115 I had used not more than a month ago with the same motherboard and graphics card as my desktop. Only the case, power suuply and disks are now different. Could there be some kind of short on the motherboard or case that could case this behavior? I remembered I had a DVICO FusionHDTV5 lying around. I don't use that card much because, in my past experience, the cx88 driver doesn't play as well with the ivtv driver as the saa7134 driver. See below for an example (*). The HDTV5 does report 0 for bER: status SCVYL | signal fd43 | snr 22a0 | ber | unc | FE_HAS_LOCK status SCVYL | signal fcde | snr 2292 | ber | unc | FE_HAS_LOCK status SCVYL | signal fd87 | snr 22b7 | ber | unc | FE_HAS_LOCK status SCVYL | signal fd65 | snr 22a4 | ber | unc | FE_HAS_LOCK status SCVYL | signal fd65 | snr 22a4 | ber | unc | FE_HAS_LOCK status SCVYL | signal fd43 | snr 2292 | ber | unc | FE_HAS_LOCK status SCVYL | signal fda9 | snr 22c5 | ber | unc | FE_HAS_LOCK status SCVYL | signal fe34 | snr 22c1 | ber | unc | FE_HAS_LOCK status SCVYL | signal fe11 | snr 22bc | ber | unc | FE_HAS_LOCK status SCVYL | signal fda9 | snr 22a0 | ber | unc | FE_HAS_LOCK In addition, the HDTV5 does not have any corruption when the x50s are active. I ran one test with the HDTV5, one 115 and two x50s. The HDTV5 didn't show corruption while the 115 did. To be sure it wasn't the content, I stopped the digital recordings and restarted them so the cards would be swapped. The corruption stayed with the 115. To summarize, I have two problems. First, the 115s show corruption when an x50 is active. This occurs on two differnt systems with Nvidia chipsets, but did not occur in a system with an Intel chipset. An HDTV in the same system does not show the corruption problem. Second, the 115s apparently can't receive a clean signal unless theer is a x50 installed and connected. (*) About half the time I boot with the HDTV5 and x50 cards, the x50 tuners don't work. The x50s will only record static until I manually unload and reload the tuner modules. In every case, the 115 reports excessive BER and UNC and capture of any digital stream is almost impossible. If this this is true then it's an RF noise issue, not a DMA issue. The encoders are generating noise that's finding it's way into your DVB frontends. Try running the DVB + 250 side by side but disconnect the antenna input to the 250 once it's running. (Ie noise is boing couple into the antenna cable) Do you still see high BER and high UNC? - Steve -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to
[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:Mon Feb 23 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/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.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
Re: PVR x50 corrupts ATSC 115 streams
On Mon, Feb 23, 2009 at 4:53 PM, Steven Toth st...@linuxtv.org wrote: Do you still see high BER and high UNC? I won't be able to try anything more until tomorrow evening. I think you're missing something, though, Steven. The In every case was in reference to without an x50 installed and connected to cable. That includes the cases where there are no x50s installed at all. How can the x50 encoder be causing noise when it's not even installed? I'm out of time. Someone else want to jump in and assist? - Steve Given David's last summary of results, it seems like the BER indicator for that particular demodulator is completely unreliable (which isn't terribly surprising). If you take that out of the equation, it seems like the only time there is corruption is when both the 115 and the x50 is encoding. So, it seems like we're back to either an RF issue or a DMA issue. Did David attempt to move the cards farther apart, or put any sort of shielding between the two cards? If the shielding has any effect, then we're probably talking about an RF issue. If it had no effect, then we are probably talking about a DMA issue. Either way, it seems like we should stop talking about the BER as any sort of indicator of a problem. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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 Monday 23 February 2009, Mauro Carvalho Chehab wrote: On Sat, 21 Feb 2009 12:53:57 +0100 Hans Verkuil hverk...@xs4all.nl wrote: Hi Adam, Sorry for the late reply, it's been very busy. Me too. 1) Reuse the existing HFLIP and VFLIP controls, marking them as read-only Pros : No change needed to videodev2.h Cons: It is confusing to have controls that have a subtly different meaning if they are read only. Existing apps that support those controls might get confused. Would require polling to support the case of a camera being turned toward / away from the user while streaming. Reusing an existing control for a different meaning seems wrong. What happens when some cam has the capability of doing hardware flipping, and have the cam flipped? I thought that case had already been agreed, implement the flip controls but set the flip flag in the hardware to the opposite of what the control says. 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. Analog tv does polling for signal strength, since userspace apps do mute and stops presenting video, if the signal is too weak. IMO, a similar mechanism should be used by pivoting. IMO, this would be better addressed as a property of v4l2_input. So, I think that (5) is better than (4). 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. 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 There is a case that we should think: at libv4l, we may need to override the default orientation, by a custom one. For example: Surveillance systems have cameras mounted on a fixed position. Depending on the camera, and the desired position, some cameras may needed to be mounted rotated (the same case also applies to some embedded hardware like ATM machines, where a webcam maybe mounted with 180 degrees, due to hardware constraints). Agreed, Hans de Geode pointed out the similar case that 2 laptops may use the same camera but one mount it upside down so hardware info unrelated to the camera indicates the orientation. Ok, this is nothing that kernel needs to handle, but, at userspace, we need to have a file where the user could edit and store the camera position, to override whatever we have in kernel. Unfortunately what that doesn't address is the problem that first started this discussion. A camera where the orientation information is contained in the USB messages from the camera so the driver is the only thing that can reasonably access it. Note also that for sensor orientation I doubt that 90 or 270 degrees rotation will be seen but I do know that the case of data being flipped on just one axis does exist. 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. Furthermore, it is only needed on devices that cannot do v/hflipping in hardware. An alternative is to put some effort in a proper event interface. There is one implemented in include/linux/dvb/video.h and used by ivtv for video decoding. The idea is that the application registers events it wants to receive, and whenever such an event arrives the select() call will exit with a high-prio event (exception). The application then checks what happened. The video.h
Re: PVR x50 corrupts ATSC 115 streams
On Mon, Feb 23, 2009 at 05:03:28PM -0500, Devin Heitmueller wrote: On Mon, Feb 23, 2009 at 4:53 PM, Steven Toth st...@linuxtv.org wrote: I'm out of time. Someone else want to jump in and assist? - Steve Given David's last summary of results, it seems like the BER indicator for that particular demodulator is completely unreliable (which isn't terribly surprising). If you take that out of the equation, it seems like the only time there is corruption is when both the 115 and the x50 is encoding. The BER isn't totally unreliable. Yes, when it's low, it does seem to be meaningless. However, when it's high, as in my recent attempts to try a 115 by itself, it indicates that nothing will work. So, it seems like we're back to either an RF issue or a DMA issue. Did David attempt to move the cards farther apart, or put any sort of shielding between the two cards? If the shielding has any effect, then we're probably talking about an RF issue. If it had no effect, then we are probably talking about a DMA issue. I tried separating the cards as far as possible. I tried shoving a small manual (~1/8 inch thick) between the 115 cards and the x50 cards to shield them. Neither action had any effect. Also, one of the tests I tried yesterday had the HDTV5 between the 115 and the x50s. The 115 showed corruption and the HDTV5 didn't even though it was nearest to the x50s. Either way, it seems like we should stop talking about the BER as any sort of indicator of a problem. David -- David Engel da...@istwok.net -- 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
running multiple DVB cards successfully.. what do I need to know?? (major and minor numbers??)
Hi All Some of you may have read some of my posts about an incorrect firmware readback message appearing in my dmesg, shortly after a tuner was engaged. I have isolated this problem, but the workaround so far has not been pretty. On a hunch I removed my Dvico Fusion HDTV lite card from the system, running now only with the Dvico Fusion Dual Express. The issue has gone, I am not getting the kdvb process hogging cpu cycles and this message has stopped. I had tried both letting the kernel (or is it udev) assign the major and minor numbers and I had tried to manually set them via modprobe.conf (formerly modules.conf, I don't know if this is a global change or specific to Gentoo) I had the major number the same for both cards, with a separate minor number for each of the three tuners, this seems to be the same. Is this how I should be setting up for 2 cards or should I be using some other type of configuration. cheers Allan -- 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
On Mon, Feb 23, 2009 at 5:48 PM, David Engel da...@istwok.net wrote: The BER isn't totally unreliable. Yes, when it's low, it does seem to be meaningless. However, when it's high, as in my recent attempts to try a 115 by itself, it indicates that nothing will work. Maybe I am missing something. Your last summary said you had a high BER even the 115 is the only card in the system. That would lead me to believe that it's always screwed up. I tried separating the cards as far as possible. I tried shoving a small manual (~1/8 inch thick) between the 115 cards and the x50 cards to shield them. Neither action had any effect. Also, one of the tests I tried yesterday had the HDTV5 between the 115 and the x50s. The 115 showed corruption and the HDTV5 didn't even though it was nearest to the x50s. Different cards interfere with each other in different ways (based on things such as the PCB layout). The fact that the HDTV5 doesn't have issues doesn't really mean *anything*. Same goes for the fact that it's BER indicator is always zero. That could just as easily indicate that the BER checking is properly implemented for that particular demod. Anyway, I don't have the card and all my suggestions were very general. If you can't find a developer with the card willing to debug the issue then you're probably SOL. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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: running multiple DVB cards successfully.. what do I need to know?? (major and minor numbers??)
Thanks Mike Is this likely to stop the Incorrect Readback of kernel version issue as well? cheers Allan On Mon Feb 23 17:57 , Michael Krufky sent: On Mon, Feb 23, 2009 at 5:49 PM, sonof...@iinet.net.au sonof...@iinet.net.au wrote: Some of you may have read some of my posts about an incorrect firmware readback message appearing in my dmesg, shortly after a tuner was engaged. I have isolated this problem, but the workaround so far has not been pretty. On a hunch I removed my Dvico Fusion HDTV lite card from the system, running now only with the Dvico Fusion Dual Express. The issue has gone, I am not getting the kdvb process hogging cpu cycles and this message has stopped. I had tried both letting the kernel (or is it udev) assign the major and minor numbers and I had tried to manually set them via modprobe.conf (formerly modules.conf, I don't know if this is a global change or specific to Gentoo) I had the major number the same for both cards, with a separate minor number for each of the three tuners, this seems to be the same. Is this how I should be setting up for 2 cards or should I be using some other type of configuration. Allan, I recommend to use the 'adapter_nr' module option. You can specify this option in modprobe.conf -- the name of this file is distro-specific. For instance, to make the dual card appear before the lite card: options cx23885 adapter_nr=0,1 options dvb-bt8xx adapter_nr=2 to make the lite card appear before the dual card: options cx23885 adapter_nr=0 options dvb-bt8xx adapter_nr=1,2 I hope you find this helpful. Regards, Mike ) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] How to pass camera Orientation to userspace
On Mon, 23 Feb 2009, Adam Baker wrote: On Monday 23 February 2009, Mauro Carvalho Chehab wrote: On Sat, 21 Feb 2009 12:53:57 +0100 Hans Verkuil hverk...@xs4all.nl wrote: Hi Adam, Sorry for the late reply, it's been very busy. Me too. big snip 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. snip Ok, this is nothing that kernel needs to handle, but, at userspace, we need to have a file where the user could edit and store the camera position, to override whatever we have in kernel. Unfortunately what that doesn't address is the problem that first started this discussion. A camera where the orientation information is contained in the USB messages from the camera so the driver is the only thing that can reasonably access it. Alas, this is so true. What started the entire discussion about passing the info about sensor orientation is a set of cameras all of which have the same Vendor:Product ID but require different handling of the data (vflip and hflip, or just vflip) depending upon information which can only be obtained by communication with the camera, *not* by just knowing its Vendor:Product ID. Therefore, it is a little bit disheartening to see discussions -- again -- which come back to some kind of internal table in V4L, or which come back to things like have a file where the user could edit and store the camera position, to override whatever we have in kernel. Repeating the obvious, which apparently still needs to be repeated because not all of the participants in the discussion get it: 1. The internal table in V4L could not handle this problem, because the internal table would be based upon what information? The USB Vendor:Product number? For that matter, no other table could work, either. Well, actually, a table could work. It would have to be inside the module supporting the camera, and the matter of which table entry corresponds to what camera would have to be settled by passing a USB command to the camera and then parsing the camera's response. So now the question is how to get the information out of the module, which can only be collected and analysed inside the module. 2. The have a file where the user could edit idea may seem attractive to some, because it shoves the whole problem of agreeing on the appropriate way to get needed information out of a kernel module and into userspace onto someone not present during the current discussion, the user. However, this is not a solution, and thinking about it just a little bit ought to make that totally obvious. This is a strongly worded statement, so I will proceed to explain why the matter is so obvious. Let us assume the very best, and assume that every app which is V4L conformant has a one time initialization step and creates a directory $HOME/.app containing stored settings. So we might have a file called $HOME/.app/sq905. This file gets automatically written when the hapless user hooks up his sq905 camera the first time, and has to go through a choice routine to decide which side of the frame is up and which side is to the left and to the right. One could even take serious steps to make this otherwise unnecessary and silly sequence to be as really nice and user friendly as it could possibly be, and set this all up to be done with a sequence of mouse clicks and then the file, very kindly, gets written automatically. Those of you who are thinking that this file a user could edit is the way to go are, presumably, thinking along these lines. Well there are at least four things which are obviously wrong with this solution: 2.1. The user is forced to deal with something which the user should not even have to confront. The user is called upon to remedy an omission and a deficiency which was ignored at a lower level, because a bunch of developers could not come together on a reasonable course of action. Well, some don't like to see this one, so there are three more reasons. 2.2 Every camera is going to require a file for itself in $HOME/.app even if there is nothing that the user needs to do. Many of the supported cameras need nothing of the kind, so this would be kind of silly. 2.3 The user has two apps for dealing with webcams. So now the user needs to have another directory called $HOME/.app2 with similar files in it? 2.4 (and this one is the worst of all) The user has two cameras which are both powered by the same kernel module, and the two cameras need two different things done. Now what??? Both cameras can not simultaneously have a valid entry in $HOME/.app/sq905 which tells what to do with the data out of the camera. Because what is right for one of them is wrong
Re: [PATCH] sh-mobile-ceu-camera: set field to the value, configured at open()
Dear Guennadi Ok, you're right again. But that's not the problem with my previous patch this time, it's that one more patch was missing - this one. And this time I even actually tested it - at least with the capture-example. I would need an mplayer or gstreamer for migor... Testing video blindly is better than no testing at all, but worse than visually:-) Thank you for your hard work. Good !!. It works well on my local environment. MigoR + ov772x + capture-example MigoR + tw9910 + capture-example Tested-by: Kuninori Morimoto morimoto.kunin...@renesas.com 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: PVR x50 corrupts ATSC 115 streams
Devin Heitmueller wrote: On Mon, Feb 23, 2009 at 5:48 PM, David Engel da...@istwok.net wrote: The BER isn't totally unreliable. Yes, when it's low, it does seem to be meaningless. However, when it's high, as in my recent attempts to try a 115 by itself, it indicates that nothing will work. Maybe I am missing something. Your last summary said you had a high BER even the 115 is the only card in the system. That would lead me to believe that it's always screwed up. I tried separating the cards as far as possible. I tried shoving a small manual (~1/8 inch thick) between the 115 cards and the x50 cards to shield them. Neither action had any effect. Also, one of the tests I tried yesterday had the HDTV5 between the 115 and the x50s. The 115 showed corruption and the HDTV5 didn't even though it was nearest to the x50s. Different cards interfere with each other in different ways (based on things such as the PCB layout). The fact that the HDTV5 doesn't have issues doesn't really mean *anything*. Same goes for the fact that it's BER indicator is always zero. That could just as easily indicate that the BER checking is properly implemented for that particular demod. Anyway, I don't have the card and all my suggestions were very general. If you can't find a developer with the card willing to debug the issue then you're probably SOL. Devin To chime in late in this conversation... David said that the original system died with these cards in it. And that the cards don't seem to work without another device in the system hooked up to the same splitter. This makes it sound like the shielding pin on these cards has been disconnected some how, and when the other device (pvrx50 in this case) is hooked up, the shielding is electrically connected through the bus somehow. When the pvrs start recording, they likely change the load on the shielding in some way that causes interference for the 115 cards. David, do you happen to have another device you could test in the system with the 2 115s, without the x50s? If this case works fine, it REALLY points to something being wrong with your 115s electrically. I'd try ohming out the shielding trace to the connector on the back of the board, if possible. Pat Erley -- 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 Mon, 23 Feb 2009, David Ellingsworth wrote: On Sun, Feb 22, 2009 at 5:15 AM, Hans Verkuil hverk...@xs4all.nl wrote: Optional question: Why can't we drop support for all but the latest kernel? Why: As others have already pointed out, it is a waste of time for developers who volunteer their time to work on supporting prior kernel revisions for use by enterprise distributions. The task of back-porting driver modifications to earlier kernels lessens the amount of time developers can focus on improving the quality and stability of new and existing drivers. Furthermore, it deters driver development since there an expectation that they will back-port their driver to earlier kernel versions. Finally, as a developer, I have We don't backport the drivers to older kernels. That's what drivers kept in a full kernel tree end up doing. Generally there is just the code for the newest kernel to think about. Most of the driver code doesn't have backward compatibility ifdefs. Most of the compat issues are handled transparently by compat.h and only those developers who patch compat.h ever need to know they exist. When a developer does need to deal with some compat ifdef in a driver, almost all the time it's something trivial and obvious. Change the variable name in both branches. Copy in a couple lines of boilerplate. Sometimes a bigger issue comes up. IIRC, around 2.6.16 there was a major class_device change in the kernel and backward compat code for it ended up being a nightmare. So we didn't do it. We stopped supporting back to ~2.6.11 and moved up the target past the problem change. Maybe this has happened again with the changes to i2c? I don't think it's that hard, but I've yet to do it myself, so maybe it is. -- 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] soc-camera: configure drivers with a default format on open
On Fri, Feb 20, 2009 at 12:20 AM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: 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(). Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- I like the idea behind this patch, but I wonder if it is compatible with standard V4L2 behaviour. Please double check against the open() comment in section 4.1.3. Image Format Negotiation below: http://v4l2spec.bytesex.org/spec/c6488.htm#AEN6520 Cheers, / magnus -- 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 Tuesday 24 February 2009 06:04:48 Trent Piepho wrote: On Mon, 23 Feb 2009, David Ellingsworth wrote: On Sun, Feb 22, 2009 at 5:15 AM, Hans Verkuil hverk...@xs4all.nl wrote: Optional question: Why can't we drop support for all but the latest kernel? Why: As others have already pointed out, it is a waste of time for developers who volunteer their time to work on supporting prior kernel revisions for use by enterprise distributions. The task of back-porting driver modifications to earlier kernels lessens the amount of time developers can focus on improving the quality and stability of new and existing drivers. Furthermore, it deters driver development since there an expectation that they will back-port their driver to earlier kernel versions. Finally, as a developer, I have We don't backport the drivers to older kernels. That's what drivers kept in a full kernel tree end up doing. Generally there is just the code for the newest kernel to think about. Most of the driver code doesn't have backward compatibility ifdefs. Most of the compat issues are handled transparently by compat.h and only those developers who patch compat.h ever need to know they exist. When a developer does need to deal with some compat ifdef in a driver, almost all the time it's something trivial and obvious. Change the variable name in both branches. Copy in a couple lines of boilerplate. Sometimes a bigger issue comes up. IIRC, around 2.6.16 there was a major class_device change in the kernel and backward compat code for it ended up being a nightmare. So we didn't do it. We stopped supporting back to ~2.6.11 and moved up the target past the problem change. Actually that was in 2.6.19. The class_device #ifs are still in e.g. v4l2-dev.c. It would be a nice bonus when we can drop that as well. It could be that there were additional changes as well in pre-2.6.16 kernels. If so, then we definitely implemented the backwards compat for it at the time. Maybe this has happened again with the changes to i2c? I don't think it's that hard, but I've yet to do it myself, so maybe it is. I've been working on this since around 2.6.24 (and been involved with i2c in one way or another for quite a bit longer) and I say it's hard. Jean Delvare made the i2c core changes in 2.6.22 and he says it's hard. So perhaps if the two people who know most about the topic say it's hard and not solvable with a compat.h change, or the occasional #if, or a regexp as Mauro seems to be attempting now, then it really IS hard. 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
