[patch] [media] staging: go7007: print the audio input type
Smatch complains that the Audio input: printk isn't reachable. Hiding the return 0; behind another statement is a style violation. It looks like audio_input is normally configured so I've enabled the print statement. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/drivers/staging/media/go7007/s2250-board.c b/drivers/staging/media/go7007/s2250-board.c index d60e065..37400bf 100644 --- a/drivers/staging/media/go7007/s2250-board.c +++ b/drivers/staging/media/go7007/s2250-board.c @@ -534,7 +534,7 @@ static int s2250_log_status(struct v4l2_subdev *sd) v4l2_info(sd, Brightness: %d\n, state-brightness); v4l2_info(sd, Contrast: %d\n, state-contrast); v4l2_info(sd, Saturation: %d\n, state-saturation); - v4l2_info(sd, Hue: %d\n, state-hue); return 0; + v4l2_info(sd, Hue: %d\n, state-hue); v4l2_info(sd, Audio input: %s\n, state-audio_input == 0 ? Line In : state-audio_input == 1 ? Mic : state-audio_input == 2 ? Mic Boost : -- 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] uvc: fix race of open and suspend in error case
Ming Lei reported:
IMO, there is a minor fault in the error handling path of
uvc_status_start() inside uvc_v4l2_open(), and the 'users' count
should have been decreased before usb_autopm_put_interface().
In theory, the warning can be triggered when the device is
opened just between usb_autopm_put_interface() and
atomic_dec(stream-dev-users).
The fix is trivial.
Signed-off-by:Oliver Neukum oneu...@suse.de
---
drivers/media/usb/uvc/uvc_v4l2.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c
index f2ee8c6..74937b7 100644
--- a/drivers/media/usb/uvc/uvc_v4l2.c
+++ b/drivers/media/usb/uvc/uvc_v4l2.c
@@ -501,8 +501,8 @@ static int uvc_v4l2_open(struct file *file)
if (atomic_inc_return(stream-dev-users) == 1) {
ret = uvc_status_start(stream-dev);
if (ret 0) {
- usb_autopm_put_interface(stream-dev-intf);
atomic_dec(stream-dev-users);
+ usb_autopm_put_interface(stream-dev-intf);
kfree(handle);
return ret;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFCv9 1/4] dvb: Add DVBv5 stats properties for Quality of Service
On Wednesday 9 January 2013 13:24:25 Mauro Carvalho Chehab wrote: snip Yes, it makes sense to document that the signal strength should be reported on either dBm or dBµW, if the scale is FE_SCALE_DECIBEL. I prefer to specify it in terms of Watt (or a submultiple) than in terms of voltage/impedance, as different Countries use different impedances on DTV cabling (typically, 50Ω or 75Ω). So, either dBm or dBµW works for me. As you said, applications can convert between those mesures as they wish, by simply adding some constant when displaying the power measure. As the wifi subsytem use dBm, I vote for using dBm for the signal measure at the subsystem (actually, 0.1 dBm). 0.1 dBm suits me. I just want something that I can present to the end user in a format that will match their aerial installer's kit. -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Changes applied
Hey all, I've applied your changes (and cleaned/fixed) them up where needed (watch those whitespaces!). I'm still only human and if I made a mistake, feel free to correct it. I've cloned the new repo from http://git.linuxtv.org/dtv-scan-tables.git to http://git.schinagl.nl/dtv-scan-tables.git and pushed them there. Once I've sorted my linuxtv.org git access I'll push there and that should be the main dtv-scan-tables repository. Once all is well I'll post future posting instructions on the linuxtv wiki and fix up dvb-apps. Oliver -- 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
[dvb] Question on dvb-core re-structure
Hi, With the new structure of dvb-core (moved up one directory), previous DVB/ATSC adapters were moved to media/usb, media/pci and media/mmc. For SoC that supports integrated DVB functionality, where should the adapter's code be located in the new structure? I don't see it fit any of the above three options. Thanks, -- Hamad Kadmany, QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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] uvc: fix race of open and suspend in error case
Hi Oliver,
Thank you for the patch.
On Thursday 10 January 2013 11:04:55 Oliver Neukum wrote:
Ming Lei reported:
IMO, there is a minor fault in the error handling path of
uvc_status_start() inside uvc_v4l2_open(), and the 'users' count
should have been decreased before usb_autopm_put_interface().
In theory, the warning can be triggered when the device is
opened just between usb_autopm_put_interface() and
atomic_dec(stream-dev-users).
The fix is trivial.
Signed-off-by:Oliver Neukum oneu...@suse.de
I've slightly modified the commit message with more details about the warning:
uvcvideo: Fix race of open and suspend in error case
Ming Lei reported:
IMO, there is a minor fault in the error handling path of
uvc_status_start() inside uvc_v4l2_open(), and the 'users' count should
have been decreased before usb_autopm_put_interface(). In theory, a [URB
resubmission] warning can be triggered when the device is opened just
between usb_autopm_put_interface() and atomic_dec(stream-dev-users).
The fix is trivial.
Reported-by: Ming Lei tom.leim...@gmail.com
Signed-off-by: Oliver Neukum oneu...@suse.de
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
The patch is in my tree, I'll push it to v3.9.
---
drivers/media/usb/uvc/uvc_v4l2.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/usb/uvc/uvc_v4l2.c
b/drivers/media/usb/uvc/uvc_v4l2.c index f2ee8c6..74937b7 100644
--- a/drivers/media/usb/uvc/uvc_v4l2.c
+++ b/drivers/media/usb/uvc/uvc_v4l2.c
@@ -501,8 +501,8 @@ static int uvc_v4l2_open(struct file *file)
if (atomic_inc_return(stream-dev-users) == 1) {
ret = uvc_status_start(stream-dev);
if (ret 0) {
- usb_autopm_put_interface(stream-dev-intf);
atomic_dec(stream-dev-users);
+ usb_autopm_put_interface(stream-dev-intf);
kfree(handle);
return ret;
}
--
Regards,
Laurent Pinchart
--
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: [dvb] Question on dvb-core re-structure
On 01/10/2013 12:44 PM, Hamad Kadmany wrote: Hi, With the new structure of dvb-core (moved up one directory), previous DVB/ATSC adapters were moved to media/usb, media/pci and media/mmc. For SoC that supports integrated DVB functionality, where should the adapter's code be located in the new structure? I don't see it fit any of the above three options. I could guess that even for the SoCs there is some bus used internally. If it is not one of those already existing, then create new directly just like one of those existing and put it there. regards Antti -- http://palosaari.fi/ -- 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] [RFC] video: display: Adding frame related ops to MIPI DSI video source struct
On Thu, 10 Jan 2013, Inki Dae inki@samsung.com wrote:
2013/1/10 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Vikas,
Thank you for the patch.
On Friday 04 January 2013 10:24:04 Vikas Sajjan wrote:
On 3 January 2013 16:29, Tomasz Figa t.f...@samsung.com wrote:
On Wednesday 02 of January 2013 18:47:22 Vikas C Sajjan wrote:
From: Vikas Sajjan vikas.saj...@linaro.org
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
include/video/display.h |6 ++
1 file changed, 6 insertions(+)
diff --git a/include/video/display.h b/include/video/display.h
index b639fd0..fb2f437 100644
--- a/include/video/display.h
+++ b/include/video/display.h
@@ -117,6 +117,12 @@ struct dsi_video_source_ops {
void (*enable_hs)(struct video_source *src, bool enable);
+ /* frame related */
+ int (*get_frame_done)(struct video_source *src);
+ int (*clear_frame_done)(struct video_source *src);
+ int (*set_early_blank_mode)(struct video_source *src, int power);
+ int (*set_blank_mode)(struct video_source *src, int power);
+
I'm not sure if all those extra ops are needed in any way.
Looking and Exynos MIPI DSIM driver, set_blank_mode is handling only
FB_BLANK_UNBLANK status, which basically equals to the already existing
enable operation, while set_early_blank mode handles only
FB_BLANK_POWERDOWN, being equal to disable callback.
Right, exynos_mipi_dsi_blank_mode() only supports FB_BLANK_UNBLANK as
of now, but FB_BLANK_NORMAL will be supported in future.
If not for Exynos, i think it will be need for other SoCs which
support FB_BLANK_UNBLANK and FB_BLANK_NORMAL.
Could you please explain in a bit more details what the set_early_blank_mode
and set_blank_mode operations do ?
Both get_frame_done and clear_frame_done do not look at anything used at
the moment and if frame done status monitoring will be ever needed, I
think a better way should be implemented.
You are right, as of now Exynos MIPI DSI Panels are NOT using these
callbacks, but as you mentioned we will need frame done status monitoring
anyways, so i included these callbacks here. Will check, if we can implement
any better method.
Do you expect the entity drivers (and in particular the panel drivers) to
require frame done notification ? If so, could you explain your use case(s) ?
Hi Laurent,
As you know, there are two types of MIPI-DSI based lcd panels, RGB and
CPU mode. In case of CPU mode lcd panel, it has its own framebuffer
internally and the image in the framebuffer is transferred on lcd
panel in 60Hz itself. But for this, there is something we should
consider. The display controller with CPU mode doens't transfer image
data to MIPI-DSI controller itself. So we should set trigger bit of
the display controller to 1 to do it and also check whether the data
transmission in the framebuffer is done on lcd panel to avoid tearing
issue and some confliction issue(A) between read and write operations
like below,
Quite right. Just to elaborate, in the MIPI DSI spec the two types are
called Video Mode and Command Mode display modules, of which the latter
has a framebuffer of its own. Update of the display module framebuffer
has to dodge the scanning of the buffer by the display module's
controller to avoid tearing. For that, info about the controller's
scanline is required. There are basically three ways for this:
1) polling the scanline using DCS get_scan_line command
2) enabling tearing effect reporting, and turning over bus ownership to
the display module for subsequent tearing effect signal (vertical
blanking) reporting by the module at the specified scanline
3) external GPIO line (outside of DSI PHY spec) to report tearing effect
signal
For an example, drivers/video/omap2/displays/panel-taal.c supports
option #2 via OMAP DSI and option #3 independently.
BR,
Jani.
lcd_panel_frame_done_interrrupt_handler()
{
...
if (mipi-dsi frame done)
trigger display controller;
...
}
A. the issue that LCD panel can access its own framebuffer while some
new data from MIPI-DSI controller is being written in the framebuffer.
But I think there might be better way to avoid such thing.
Thanks,
Inki Dae
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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: [dvb] Question on dvb-core re-structure
On 01/10/2013 1:13 PM, Antti Palosaari wrote: I could guess that even for the SoCs there is some bus used internally. If it is not one of those already existing, then create new directly just like one of those existing and put it there. Thanks for the answer. I just wanted to clarify - it's integrated into the chip and accessed via memory mapped registers, so I'm not sure which category to give the new directory (parallel to pci/mms/usb). Should I just put the adapter's sources directory directly under media directory? Thanks, -- Hamad Kadmany, QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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: [dvb] Question on dvb-core re-structure
Em Thu, 10 Jan 2013 12:44:14 +0200 Hamad Kadmany hkadm...@codeaurora.org escreveu: Hi, With the new structure of dvb-core (moved up one directory), previous DVB/ATSC adapters were moved to media/usb, media/pci and media/mmc. For SoC that supports integrated DVB functionality, where should the adapter's code be located in the new structure? I don't see it fit any of the above three options. It should be inside drivers/media/platform. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [dvb] Question on dvb-core re-structure
Em Thu, 10 Jan 2013 13:49:52 +0200 Hamad Kadmany hkadm...@codeaurora.org escreveu: On 01/10/2013 1:13 PM, Antti Palosaari wrote: I could guess that even for the SoCs there is some bus used internally. If it is not one of those already existing, then create new directly just like one of those existing and put it there. Thanks for the answer. I just wanted to clarify - it's integrated into the chip and accessed via memory mapped registers, so I'm not sure which category to give the new directory (parallel to pci/mms/usb). Should I just put the adapter's sources directory directly under media directory? That's the case of all other drivers under drivers/media/platform: they're IP blocks inside the SoC chip. I think that all arch-dependent drivers are there. The menu needs to be renamed to Media platform drivers when the first DVB driver arrives there (it currently says V4L, as there's no DVB driver there yet). Feel free to add such patch on your patch series at the time you submit your driver, if nobody else submit any DVB platform driver earlier than yours. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: global mutex in dvb_usercopy (dvbdev.c)
Em Thu, 10 Jan 2013 03:06:51 +0100 thomas schorpp thomas.scho...@gmail.com escreveu: On 09.01.2013 22:30, Nikolaus Schulz wrote: On Tue, Jan 08, 2013 at 12:05:47PM +0530, Soby Mathew wrote: Hi Everyone, I have a doubt regarding about the global mutex lock in dvb_usercopy(drivers/media/dvb-core/dvbdev.c, line 382) . /* call driver */ mutex_lock(dvbdev_mutex); if ((err = func(file, cmd, parg)) == -ENOIOCTLCMD) err = -EINVAL; mutex_unlock(dvbdev_mutex); Why is this mutex needed? When I check similar functions like video_usercopy, this kind of global locking is not present when func() is called. I cannot say anything about video_usercopy(), but as it happens, there's a patch[1] queued for Linux 3.9 that will hopefully replace the mutex in dvb_usercopy() with more fine-grained locking. Nikolaus [1] http://git.linuxtv.org/media_tree.git/commit/30ad64b8ac539459f8975aa186421ef3db0bb5cb Unfortunately, frontend ioctls can be blocked by the frontend thread for several seconds; this leads to unacceptable lock contention. Especially the stv0297 signal locking, as it turned out in situations of bad signal input or my cable providers outtage today it has slowed down dvb_ttpci (notable as OSD- output latency and possibly driver buffer overflows of budget source devices) that much that I had to disable tuning with parm --outputonly in vdr-plugin-dvbsddevice. Can anyone confirm that and have a look at the other frontend drivers for tuners needing as much driver control? I will try to apply the patch manually to Linux 3.2 and check with Latencytop tomorrow. Well, an ioctl's should not block for a long time, if the device is opened with O_NONBLOCK. Unfortunately, not all drivers follow this rule, and blocks. The right fix seem to have a logic at stv0297 that would do the signal locking in background, or to use the already-existent DVB frontend thread, and answering to userspace the last cached result, instead of actively talking with the frontend device driver. Both approaches have advantages and disadvantages. In any case, a change like that at dvb core has the potential of causing troubles to userspace, although I think it is the better thing to do, at the long term. y tom -- 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 -- 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: [dvb] Question on dvb-core re-structure
Mauro Carvalho Chehab writes: Em Thu, 10 Jan 2013 13:49:52 +0200 Hamad Kadmany hkadm...@codeaurora.org escreveu: On 01/10/2013 1:13 PM, Antti Palosaari wrote: I could guess that even for the SoCs there is some bus used internally. If it is not one of those already existing, then create new directly just like one of those existing and put it there. Thanks for the answer. I just wanted to clarify - it's integrated into the chip and accessed via memory mapped registers, so I'm not sure which category to give the new directory (parallel to pci/mms/usb). Should I just put the adapter's sources directory directly under media directory? That's the case of all other drivers under drivers/media/platform: they're IP blocks inside the SoC chip. I think that all arch-dependent drivers are there. The menu needs to be renamed to Media platform drivers when the first DVB driver arrives there (it currently says V4L, as there's no DVB driver there yet). Feel free to add such patch on your patch series at the time you submit your driver, if nobody else submit any DVB platform driver earlier than yours. What about DVB cores which can be used via different busses? E.g. ddbridge initially only used PCIe. Now we also use the same function blocks (I2C, DVB input, etc.) connected to a SoC via an EBI (extension bus interface) and register it as a platform device. Because a lot of code can be shared I do not want to split it over several directories. Regards, Ralph -- 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: [dvb] Question on dvb-core re-structure
Em Thu, 10 Jan 2013 17:01:57 +0100 Ralph Metzler r...@metzlerbros.de escreveu: Mauro Carvalho Chehab writes: Em Thu, 10 Jan 2013 13:49:52 +0200 Hamad Kadmany hkadm...@codeaurora.org escreveu: On 01/10/2013 1:13 PM, Antti Palosaari wrote: I could guess that even for the SoCs there is some bus used internally. If it is not one of those already existing, then create new directly just like one of those existing and put it there. Thanks for the answer. I just wanted to clarify - it's integrated into the chip and accessed via memory mapped registers, so I'm not sure which category to give the new directory (parallel to pci/mms/usb). Should I just put the adapter's sources directory directly under media directory? That's the case of all other drivers under drivers/media/platform: they're IP blocks inside the SoC chip. I think that all arch-dependent drivers are there. The menu needs to be renamed to Media platform drivers when the first DVB driver arrives there (it currently says V4L, as there's no DVB driver there yet). Feel free to add such patch on your patch series at the time you submit your driver, if nobody else submit any DVB platform driver earlier than yours. What about DVB cores which can be used via different busses? E.g. ddbridge initially only used PCIe. Now we also use the same function blocks (I2C, DVB input, etc.) connected to a SoC via an EBI (extension bus interface) and register it as a platform device. Because a lot of code can be shared I do not want to split it over several directories. What we're doing on such cases is to put the common stuff under drivers/media/common and the bus-specific (or platform-specific) code under drivers/media/pci, drivers/media/usb, drivers/media/mmc, etc. There are, currenlty, 3 drivers like that: saa7146 (the common code were always stored at /common), b2c2 and siano. 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: dvb-apps - scan-s2 szap-s2
Em Thu, 10 Jan 2013 20:40:41 +0400 Goga777 goga...@bk.ru escreveu: Hi is there any plans to update dvb-apps repo and to add in it actual version of scan-s2 and szap-s2 ? Nobody is maintaining dvb-apps for a long time. I wrote a few years ago a patch adding DVBv5 support there at dvb-apps, but it was very complex, as, internally, it has an abstraction layer that it is too bound to the way the DVBv3 API works, IMHO. It ends that rewriting from scratch were simpler than fixing dvb-apps for every single new delivery system. If you want to use scan/zap with a delivery system different than DVB-T/C/S or ATSC, I suggest you to use dvbv5 tools at: http://git.linuxtv.org/v4l-utils.git They were written to work with DVBv5 API (it also supports DVBv3 - of course without S2/T2 support) and should work with DVB-S2, DVB-T2, etc. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Initial scan files troubles and brainstorming
On 1/9/13, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Wed, 9 Jan 2013 06:08:44 -0500 Michael Krufky mkru...@linuxtv.org escreveu: On Wed, Jan 9, 2013 at 5:41 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Wed, 09 Jan 2013 10:43:23 +0100 Oliver Schinagl oliver+l...@schinagl.nl escreveu: On 08-01-13 21:01, Johannes Stezenbach wrote: On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote: On 07-01-13 11:46, Jiri Slaby wrote: On 12/18/2012 11:01 PM, Oliver Schinagl wrote: Unfortunatly, I have had zero replies. Hmm, it's sad there is a silence in this thread from linux-media guys :/. In their defense, they are very very busy people ;) chatter on this thread does bring it up however. This is such a nice thing to say :-) But it might be that Mauro thinks the dvb-apps maintainer should respond, but apparently there is no dvb-apps maintainer... Maybe you should ask Mauro directly to create an account for you to implement what you proposed. Mauro is CC'ed and I'd ask of course for this (I kinda did) but who decides what I suggested is a good idea? I personally obviously think it is ;) and even more so if dvb-apps are unmaintained. I guess the question now becomes 'who okay's this change? Who says 'okay, lets do it this way. Once that is answered we can go from there ;) If I understood it right, you want to split the scan files into a separate git tree and maintain it, right? I'm ok with that. Regards, Mauro As a DVB maintainer, I am OK with this as well - It does indeed make sense to separate the c code sources from the regional frequency tables, and I'm sure we'll see much benefit from this change. Done. I created a tree for Oliver to maintain it and an account for him. I also created a new tree with just the DVB table commits to: http://git.linuxtv.org/dtv-scan-tables.git I kept there both szap and scan files, although maybe it makes sense to drop the szap table (channels-conf dir). It also makes sense to drop the tables from the dvb-apps tree, to avoid duplicated stuff, and to avoid Being one of the maintainers: I will keep the tables in the dvb-apps tree for the time being. Will decide to drop the config files as needed from dvb-apps. It is necessary to keep a copy of the config files for development purposes, rather than pulling from different trees. Manu -- 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] Initial scan files troubles and brainstorming
On 01/10/2013 06:40 PM, Manu Abraham wrote: On 1/9/13, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Wed, 9 Jan 2013 06:08:44 -0500 Michael Krufky mkru...@linuxtv.org escreveu: On Wed, Jan 9, 2013 at 5:41 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Wed, 09 Jan 2013 10:43:23 +0100 Oliver Schinagl oliver+l...@schinagl.nl escreveu: On 08-01-13 21:01, Johannes Stezenbach wrote: On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote: On 07-01-13 11:46, Jiri Slaby wrote: On 12/18/2012 11:01 PM, Oliver Schinagl wrote: Unfortunatly, I have had zero replies. Hmm, it's sad there is a silence in this thread from linux-media guys :/. In their defense, they are very very busy people ;) chatter on this thread does bring it up however. This is such a nice thing to say :-) But it might be that Mauro thinks the dvb-apps maintainer should respond, but apparently there is no dvb-apps maintainer... Maybe you should ask Mauro directly to create an account for you to implement what you proposed. Mauro is CC'ed and I'd ask of course for this (I kinda did) but who decides what I suggested is a good idea? I personally obviously think it is ;) and even more so if dvb-apps are unmaintained. I guess the question now becomes 'who okay's this change? Who says 'okay, lets do it this way. Once that is answered we can go from there ;) If I understood it right, you want to split the scan files into a separate git tree and maintain it, right? I'm ok with that. Regards, Mauro As a DVB maintainer, I am OK with this as well - It does indeed make sense to separate the c code sources from the regional frequency tables, and I'm sure we'll see much benefit from this change. Done. I created a tree for Oliver to maintain it and an account for him. I also created a new tree with just the DVB table commits to: http://git.linuxtv.org/dtv-scan-tables.git I kept there both szap and scan files, although maybe it makes sense to drop the szap table (channels-conf dir). It also makes sense to drop the tables from the dvb-apps tree, to avoid duplicated stuff, and to avoid Being one of the maintainers: I will keep the tables in the dvb-apps tree for the time being. That does not make sense at all -- why? Duplicated stuff always hurts. Will decide to drop the config files as needed from dvb-apps. It is necessary to keep a copy of the config files for development purposes, rather than pulling from different trees. What development purposes, could you be more specific? You can still use git submodules if really needed. But as it stands I do not see a reason for that at all... regards, -- js -- 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] Initial scan files troubles and brainstorming
On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote: On 01/10/2013 06:40 PM, Manu Abraham wrote: On 1/9/13, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Wed, 9 Jan 2013 06:08:44 -0500 Michael Krufky mkru...@linuxtv.org escreveu: On Wed, Jan 9, 2013 at 5:41 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Wed, 09 Jan 2013 10:43:23 +0100 Oliver Schinagl oliver+l...@schinagl.nl escreveu: On 08-01-13 21:01, Johannes Stezenbach wrote: On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote: On 07-01-13 11:46, Jiri Slaby wrote: On 12/18/2012 11:01 PM, Oliver Schinagl wrote: Unfortunatly, I have had zero replies. Hmm, it's sad there is a silence in this thread from linux-media guys :/. In their defense, they are very very busy people ;) chatter on this thread does bring it up however. This is such a nice thing to say :-) But it might be that Mauro thinks the dvb-apps maintainer should respond, but apparently there is no dvb-apps maintainer... Maybe you should ask Mauro directly to create an account for you to implement what you proposed. Mauro is CC'ed and I'd ask of course for this (I kinda did) but who decides what I suggested is a good idea? I personally obviously think it is ;) and even more so if dvb-apps are unmaintained. I guess the question now becomes 'who okay's this change? Who says 'okay, lets do it this way. Once that is answered we can go from there ;) If I understood it right, you want to split the scan files into a separate git tree and maintain it, right? I'm ok with that. Regards, Mauro As a DVB maintainer, I am OK with this as well - It does indeed make sense to separate the c code sources from the regional frequency tables, and I'm sure we'll see much benefit from this change. Done. I created a tree for Oliver to maintain it and an account for him. I also created a new tree with just the DVB table commits to: http://git.linuxtv.org/dtv-scan-tables.git I kept there both szap and scan files, although maybe it makes sense to drop the szap table (channels-conf dir). It also makes sense to drop the tables from the dvb-apps tree, to avoid duplicated stuff, and to avoid Being one of the maintainers: I will keep the tables in the dvb-apps tree for the time being. That does not make sense at all -- why? Duplicated stuff always hurts. The scan files and config files are very specific to dvb-apps, some applications do rely on these config files. It doesn't really make sense to have split out config files for these small applications. Will decide to drop the config files as needed from dvb-apps. It is necessary to keep a copy of the config files for development purposes, rather than pulling from different trees. What development purposes, could you be more specific? You can still use git submodules if really needed. But as it stands I do not see a reason for that at all... Did you think that the dvb-apps just came out of thin air ? development of dvb-applications, implies eventually config files also will be updated as necessary. Having them in separate repositories makes such work harder for working. while working with dvb-apps, it would make things saner if it is the same SCM, rather than having different SCM's. So according to you, you want to make it still harder for someone to work with dvb-apps. Manu -- 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] Initial scan files troubles and brainstorming
On Thu, Jan 10, 2013 at 1:46 PM, Manu Abraham abraham.m...@gmail.com wrote: On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote: On 01/10/2013 06:40 PM, Manu Abraham wrote: On 1/9/13, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Wed, 9 Jan 2013 06:08:44 -0500 Michael Krufky mkru...@linuxtv.org escreveu: On Wed, Jan 9, 2013 at 5:41 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Wed, 09 Jan 2013 10:43:23 +0100 Oliver Schinagl oliver+l...@schinagl.nl escreveu: On 08-01-13 21:01, Johannes Stezenbach wrote: On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote: On 07-01-13 11:46, Jiri Slaby wrote: On 12/18/2012 11:01 PM, Oliver Schinagl wrote: Unfortunatly, I have had zero replies. Hmm, it's sad there is a silence in this thread from linux-media guys :/. In their defense, they are very very busy people ;) chatter on this thread does bring it up however. This is such a nice thing to say :-) But it might be that Mauro thinks the dvb-apps maintainer should respond, but apparently there is no dvb-apps maintainer... Maybe you should ask Mauro directly to create an account for you to implement what you proposed. Mauro is CC'ed and I'd ask of course for this (I kinda did) but who decides what I suggested is a good idea? I personally obviously think it is ;) and even more so if dvb-apps are unmaintained. I guess the question now becomes 'who okay's this change? Who says 'okay, lets do it this way. Once that is answered we can go from there ;) If I understood it right, you want to split the scan files into a separate git tree and maintain it, right? I'm ok with that. Regards, Mauro As a DVB maintainer, I am OK with this as well - It does indeed make sense to separate the c code sources from the regional frequency tables, and I'm sure we'll see much benefit from this change. Done. I created a tree for Oliver to maintain it and an account for him. I also created a new tree with just the DVB table commits to: http://git.linuxtv.org/dtv-scan-tables.git I kept there both szap and scan files, although maybe it makes sense to drop the szap table (channels-conf dir). It also makes sense to drop the tables from the dvb-apps tree, to avoid duplicated stuff, and to avoid Being one of the maintainers: I will keep the tables in the dvb-apps tree for the time being. That does not make sense at all -- why? Duplicated stuff always hurts. The scan files and config files are very specific to dvb-apps, some applications do rely on these config files. It doesn't really make sense to have split out config files for these small applications. Will decide to drop the config files as needed from dvb-apps. It is necessary to keep a copy of the config files for development purposes, rather than pulling from different trees. What development purposes, could you be more specific? You can still use git submodules if really needed. But as it stands I do not see a reason for that at all... Did you think that the dvb-apps just came out of thin air ? development of dvb-applications, implies eventually config files also will be updated as necessary. Having them in separate repositories makes such work harder for working. while working with dvb-apps, it would make things saner if it is the same SCM, rather than having different SCM's. So according to you, you want to make it still harder for someone to work with dvb-apps. Manu Manu, I see great value in separating the history of the data files from the code files. If you really think this is such a terrible task for a developer to have to pull from a second repository to fetch these data files, then I find no reason why we couldn't script it such that building the dvb-apps package would trigger the pull from the additional repository. I think that's a fair compromise. Meanwhile, your argument is for developers. Developers can handle pulling from a separated tree for data files who shouldn't be clouding the history of source code development, anyway. Developers are indeed used to dealing with multiple repositories, and if any developer isn't, then now is the time to get with the program! I think this change is a great idea, and I would hope that we'd all agree on this, at least. Best Regards, Mike Krufky -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Initial scan files troubles and brainstorming
On 01/10/2013 07:46 PM, Manu Abraham wrote: The scan files and config files are very specific to dvb-apps, some applications do rely on these config files. It doesn't really make sense to have split out config files for these small applications. I don't care where they are, really. However I'm strongly against duplicating them. Feel free to remove the newly created repository, I'll be fine with that. So according to you, you want to make it still harder for someone to work with dvb-apps. I wasn't the one to suggest a separate directory for the data, there is no point in blaming me... -- js -- 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] Initial scan files troubles and brainstorming
On 01/10/2013 07:56 PM, Michael Krufky wrote: I see great value in separating the history of the data files from the code files. If you really think this is such a terrible task for a developer to have to pull from a second repository to fetch these data files, then I find no reason why we couldn't script it such that building the dvb-apps package would trigger the pull from the additional repository. (Or use submodules.) -- js -- 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] Initial scan files troubles and brainstorming
On 1/11/13, Michael Krufky mkru...@linuxtv.org wrote: On Thu, Jan 10, 2013 at 1:46 PM, Manu Abraham abraham.m...@gmail.com wrote: On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote: On 01/10/2013 06:40 PM, Manu Abraham wrote: On 1/9/13, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Wed, 9 Jan 2013 06:08:44 -0500 Michael Krufky mkru...@linuxtv.org escreveu: On Wed, Jan 9, 2013 at 5:41 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Wed, 09 Jan 2013 10:43:23 +0100 Oliver Schinagl oliver+l...@schinagl.nl escreveu: On 08-01-13 21:01, Johannes Stezenbach wrote: On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote: On 07-01-13 11:46, Jiri Slaby wrote: On 12/18/2012 11:01 PM, Oliver Schinagl wrote: Unfortunatly, I have had zero replies. Hmm, it's sad there is a silence in this thread from linux-media guys :/. In their defense, they are very very busy people ;) chatter on this thread does bring it up however. This is such a nice thing to say :-) But it might be that Mauro thinks the dvb-apps maintainer should respond, but apparently there is no dvb-apps maintainer... Maybe you should ask Mauro directly to create an account for you to implement what you proposed. Mauro is CC'ed and I'd ask of course for this (I kinda did) but who decides what I suggested is a good idea? I personally obviously think it is ;) and even more so if dvb-apps are unmaintained. I guess the question now becomes 'who okay's this change? Who says 'okay, lets do it this way. Once that is answered we can go from there ;) If I understood it right, you want to split the scan files into a separate git tree and maintain it, right? I'm ok with that. Regards, Mauro As a DVB maintainer, I am OK with this as well - It does indeed make sense to separate the c code sources from the regional frequency tables, and I'm sure we'll see much benefit from this change. Done. I created a tree for Oliver to maintain it and an account for him. I also created a new tree with just the DVB table commits to: http://git.linuxtv.org/dtv-scan-tables.git I kept there both szap and scan files, although maybe it makes sense to drop the szap table (channels-conf dir). It also makes sense to drop the tables from the dvb-apps tree, to avoid duplicated stuff, and to avoid Being one of the maintainers: I will keep the tables in the dvb-apps tree for the time being. That does not make sense at all -- why? Duplicated stuff always hurts. The scan files and config files are very specific to dvb-apps, some applications do rely on these config files. It doesn't really make sense to have split out config files for these small applications. Will decide to drop the config files as needed from dvb-apps. It is necessary to keep a copy of the config files for development purposes, rather than pulling from different trees. What development purposes, could you be more specific? You can still use git submodules if really needed. But as it stands I do not see a reason for that at all... Did you think that the dvb-apps just came out of thin air ? development of dvb-applications, implies eventually config files also will be updated as necessary. Having them in separate repositories makes such work harder for working. while working with dvb-apps, it would make things saner if it is the same SCM, rather than having different SCM's. So according to you, you want to make it still harder for someone to work with dvb-apps. Manu Manu, I see great value in separating the history of the data files from the code files. If you really think this is such a terrible task for a developer to have to pull from a second repository to fetch these data files, then I find no reason why we couldn't script it such that building the dvb-apps package would trigger the pull from the additional repository. I think that's a fair compromise. As someone who has long been working with dvb-apps, I see no value in this, but just pain altogether. For people who have never worked with it, they can say anything what they want, which makes no sense at all. Meanwhile, your argument is for developers. Developers can handle pulling from a separated tree for data files who shouldn't be clouding the history of source code development, anyway. Developers are indeed used to dealing with multiple repositories, and if any developer isn't, then now is the time to get with the program! It isn't that way. Users have to deal with 2 repositories as well. Anyway, the repository is not having that many developers to state that developers can handle all the burden. It is just but the reverse. Manu -- 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] Initial scan files troubles and brainstorming
On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote: On 01/10/2013 07:46 PM, Manu Abraham wrote: The scan files and config files are very specific to dvb-apps, some applications do rely on these config files. It doesn't really make sense to have split out config files for these small applications. I don't care where they are, really. However I'm strongly against duplicating them. Feel free to remove the newly created repository, I'll be fine with that. I haven't duplicated anything at all. It is Mauro who has duplicated stuff, by creating a new tree altogether. if you need the scan files to be properly maintained then you need to handle it in the same repository altogether. Not by separating out the configuration files of a few applications. Manu -- 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] Initial scan files troubles and brainstorming
On 01/10/2013 08:08 PM, Manu Abraham wrote: On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote: On 01/10/2013 07:46 PM, Manu Abraham wrote: The scan files and config files are very specific to dvb-apps, some applications do rely on these config files. It doesn't really make sense to have split out config files for these small applications. I don't care where they are, really. However I'm strongly against duplicating them. Feel free to remove the newly created repository, I'll be fine with that. I haven't duplicated anything at all. It is Mauro who has duplicated stuff, by creating a new tree altogether. I didn't accuse you. This was a general comment to everybody. Whatever the consensus is at the end, do not duplicate the data. if you need the scan files to be properly maintained then you need to handle it in the same repository altogether. Not by separating out the configuration files of a few applications. That's up to you guys to decide. I don't mind either option. -- js -- 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] Initial scan files troubles and brainstorming
On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote: On 01/10/2013 08:08 PM, Manu Abraham wrote: On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote: On 01/10/2013 07:46 PM, Manu Abraham wrote: The scan files and config files are very specific to dvb-apps, some applications do rely on these config files. It doesn't really make sense to have split out config files for these small applications. I don't care where they are, really. However I'm strongly against duplicating them. Feel free to remove the newly created repository, I'll be fine with that. I haven't duplicated anything at all. It is Mauro who has duplicated stuff, by creating a new tree altogether. I didn't accuse you. This was a general comment to everybody. Whatever the consensus is at the end, do not duplicate the data. Eventually what will happen is that, as applications do get developed, the config files which are alongwith the applications will have proper compatibility with the applications while, the split out config files will be in a different state, providing nothing but pain for everyone. Manu -- 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: dvb-apps - scan-s2 szap-s2
If you want to use scan/zap with a delivery system different than DVB-T/C/S or ATSC, I suggest you to use dvbv5 tools at: http://git.linuxtv.org/v4l-utils.git and what about dvb-t/s support in dvbv5 tools ? how to scan/zap dvb-s transponders ? -- 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] Initial scan files troubles and brainstorming
Em Fri, 11 Jan 2013 00:38:18 +0530 Manu Abraham abraham.m...@gmail.com escreveu: On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote: On 01/10/2013 07:46 PM, Manu Abraham wrote: The scan files and config files are very specific to dvb-apps, some applications do rely on these config files. It doesn't really make sense to have split out config files for these small applications. I don't care where they are, really. However I'm strongly against duplicating them. Feel free to remove the newly created repository, I'll be fine with that. I haven't duplicated anything at all. It is Mauro who has duplicated stuff, by creating a new tree altogether. I only did it by request, and after having some consensus at the ML, and after people explicitly asking me to do that. I even tried to not express my opinion to anybody. But it seems I'm forced by you to give it. So, let it be. The last patches from you there were 11 months ago, and didn't bring any new functionality there... they are just indentation fixes: http://www.linuxtv.org/hg/dvb-apps/ The last one with a new functionality seems to be this one, 15 months ago: http://www.linuxtv.org/hg/dvb-apps/rev/d4e8bf5658ce Also, people find a very bad time when they submit any fixes for the driver you wrote, as you doesn't seem to have enough time to review their patches. So, I suspect that you're a very very busy person, with almost no time to maintain your previous work. If something has changed, and you're now finding more time, I'd pleased if you could review the patches that are there for a long time (there is one from 2011 that it is a rebase of an even older patch) before re-doing Oliver's scanfile updates at dvb-tools: http://www.spinics.net/lists/linux-media/msg58283.html Considering that nobody is having much time for the dvb-apps tree nowadays, I really think that it would be great to get someone with more time to maintain those files, as otherwise the update scan files may be on the limbo for a long time, and releasing us to have more time with development. As proposed by Oliver, it seemed to be a good idea to have it on a separate tree, as those scan files are actually independent of the dvb-apps, and can be used by other applications. That's why I welcomed Oliver's initiative to maintain it, and I wish him a good work with that. Eventually what will happen is that, as applications do get developed, the config files which are alongwith the applications will have proper compatibility with the applications while, the split out config files will be in a different state, providing nothing but pain for everyone. The format of those files can't be changed without breaking other existing applications that relies on its format, like mplayer, vlc, etc. It could make sense, though, to convert them in the future to a more generic format that would be delivery-system independent and that could easily be converted into all application-specific formats, and add there some format-change tool that would dynamically generate the files at vdr, dvb-apps, kaffeine... format. By having it on a separate tree, with its own maintainer, Oliver can focus on it, without needing to be bothered with maintaining the dvb-apps. So, it makes all sense for me to have it maintained in separate. That's said, there's no problem on having those files maintained on two or more trees. Actually, there are already dozens of forks of it, as each distribution has its own dvb-apps fork, some outdated and eventually some with their own scan files there. So, if no agreement is reached, I would just keep it as is for a while and review it maybe an year later. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Initial scan files troubles and brainstorming
On 01/10/13 20:04, Manu Abraham wrote: On 1/11/13, Michael Krufky mkru...@linuxtv.org wrote: On Thu, Jan 10, 2013 at 1:46 PM, Manu Abraham abraham.m...@gmail.com wrote: On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote: On 01/10/2013 06:40 PM, Manu Abraham wrote: On 1/9/13, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Wed, 9 Jan 2013 06:08:44 -0500 Michael Krufky mkru...@linuxtv.org escreveu: On Wed, Jan 9, 2013 at 5:41 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Wed, 09 Jan 2013 10:43:23 +0100 Oliver Schinagl oliver+l...@schinagl.nl escreveu: On 08-01-13 21:01, Johannes Stezenbach wrote: On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote: On 07-01-13 11:46, Jiri Slaby wrote: On 12/18/2012 11:01 PM, Oliver Schinagl wrote: Unfortunatly, I have had zero replies. Hmm, it's sad there is a silence in this thread from linux-media guys :/. In their defense, they are very very busy people ;) chatter on this thread does bring it up however. This is such a nice thing to say :-) But it might be that Mauro thinks the dvb-apps maintainer should respond, but apparently there is no dvb-apps maintainer... Maybe you should ask Mauro directly to create an account for you to implement what you proposed. Mauro is CC'ed and I'd ask of course for this (I kinda did) but who decides what I suggested is a good idea? I personally obviously think it is ;) and even more so if dvb-apps are unmaintained. I guess the question now becomes 'who okay's this change? Who says 'okay, lets do it this way. Once that is answered we can go from there ;) If I understood it right, you want to split the scan files into a separate git tree and maintain it, right? I'm ok with that. Regards, Mauro As a DVB maintainer, I am OK with this as well - It does indeed make sense to separate the c code sources from the regional frequency tables, and I'm sure we'll see much benefit from this change. Done. I created a tree for Oliver to maintain it and an account for him. I also created a new tree with just the DVB table commits to: http://git.linuxtv.org/dtv-scan-tables.git I kept there both szap and scan files, although maybe it makes sense to drop the szap table (channels-conf dir). It also makes sense to drop the tables from the dvb-apps tree, to avoid duplicated stuff, and to avoid Being one of the maintainers: I will keep the tables in the dvb-apps tree for the time being. That does not make sense at all -- why? Duplicated stuff always hurts. The scan files and config files are very specific to dvb-apps, some applications do rely on these config files. It doesn't really make sense to have split out config files for these small applications. Will decide to drop the config files as needed from dvb-apps. It is necessary to keep a copy of the config files for development purposes, rather than pulling from different trees. What development purposes, could you be more specific? You can still use git submodules if really needed. But as it stands I do not see a reason for that at all... Did you think that the dvb-apps just came out of thin air ? development of dvb-applications, implies eventually config files also will be updated as necessary. Having them in separate repositories makes such work harder for working. while working with dvb-apps, it would make things saner if it is the same SCM, rather than having different SCM's. So according to you, you want to make it still harder for someone to work with dvb-apps. Manu Manu, I see great value in separating the history of the data files from the code files. If you really think this is such a terrible task for a developer to have to pull from a second repository to fetch these data files, then I find no reason why we couldn't script it such that building the dvb-apps package would trigger the pull from the additional repository. I think that's a fair compromise. As someone who has long been working with dvb-apps, I see no value in this, but just pain altogether. For people who have never worked with it, they can say anything what they want, which makes no sense at all. Well there are a few apps that do use the initial scanfile tree, but do not use any of the dvb-apps. (tvheadend, kaffeine appearantly, i'm guessing VDR and MythTV aswell?) Meanwhile, your argument is for developers. Developers can handle pulling from a separated tree for data files who shouldn't be clouding the history of source code development, anyway. Developers are indeed used to dealing with multiple repositories, and if any developer isn't, then now is the time to get with the program! It isn't that way. Users have to deal with 2 repositories as well. Anyway, the repository is not having that many developers to state that developers can handle all the burden. It is just but the reverse. Well one of the biggest issues was, that the scanfiles where ill maintained and projects where working around those shortcommings. The scanfiles are
Re: [RFC] Initial scan files troubles and brainstorming
On 1/11/13, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Fri, 11 Jan 2013 00:38:18 +0530 Manu Abraham abraham.m...@gmail.com escreveu: On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote: On 01/10/2013 07:46 PM, Manu Abraham wrote: The scan files and config files are very specific to dvb-apps, some applications do rely on these config files. It doesn't really make sense to have split out config files for these small applications. I don't care where they are, really. However I'm strongly against duplicating them. Feel free to remove the newly created repository, I'll be fine with that. I haven't duplicated anything at all. It is Mauro who has duplicated stuff, by creating a new tree altogether. I only did it by request, and after having some consensus at the ML, and after people explicitly asking me to do that. Having consensus implies that the people involved with it are in that loop, rather than having a superfluous one with no one of it in that loop. Manu -- 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] Initial scan files troubles and brainstorming
On 1/11/13, Oliver Schinagl oliver+l...@schinagl.nl wrote: they can say anything what they want, which makes no sense at all. Well there are a few apps that do use the initial scanfile tree, but do not use any of the dvb-apps. (tvheadend, kaffeine appearantly, i'm guessing VDR and MythTV aswell?) Only tvheadend and kaffeine AFAIK. VDR and MythTV have their own formats. Meanwhile, your argument is for developers. Developers can handle pulling from a separated tree for data files who shouldn't be clouding the history of source code development, anyway. Developers are indeed used to dealing with multiple repositories, and if any developer isn't, then now is the time to get with the program! It isn't that way. Users have to deal with 2 repositories as well. Anyway, the repository is not having that many developers to state that developers can handle all the burden. It is just but the reverse. Well one of the biggest issues was, that the scanfiles where ill maintained and projects where working around those shortcommings. The scanfiles are technically unrelated. They are data files, facts and can very logically live seperated :) Having commit messages pure for data files in a source tree just looks off. The configuration files/data for dvb-apps. They simply have become a seperate entity as people (not developers) depend on them. (Yes there is wscan of course). Also, purely out of curiousity, how are the scanfiles used during development? The scanfiles what you call them are the configuration files for dvb-apps, rather than purely data files. Manu -- 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] Initial scan files troubles and brainstorming
On 1/11/13, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Fri, 11 Jan 2013 00:38:18 +0530 Manu Abraham abraham.m...@gmail.com escreveu: On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote: On 01/10/2013 07:46 PM, Manu Abraham wrote: The scan files and config files are very specific to dvb-apps, some applications do rely on these config files. It doesn't really make sense to have split out config files for these small applications. I don't care where they are, really. However I'm strongly against duplicating them. Feel free to remove the newly created repository, I'll be fine with that. I haven't duplicated anything at all. It is Mauro who has duplicated stuff, by creating a new tree altogether. I only did it by request, and after having some consensus at the ML, and after people explicitly asking me to do that. I even tried to not express my opinion to anybody. But it seems I'm forced by you to give it. So, let it be. The last patches from you there were 11 months ago, and didn't bring any new functionality there... they are just indentation fixes: http://www.linuxtv.org/hg/dvb-apps/ The way you do things, it all ends up like this. https://lkml.org/lkml/2012/12/23/75 Manu -- 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] Initial scan files troubles and brainstorming
On 01/10/2013 09:25 PM, Manu Abraham wrote: Also, purely out of curiousity, how are the scanfiles used during development? The scanfiles what you call them are the configuration files for dvb-apps, rather than purely data files. But you cannot change their format, so what's the point? You can use them from a different directory or system ones... -- js -- 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] Initial scan files troubles and brainstorming
Em Fri, 11 Jan 2013 01:55:34 +0530 Manu Abraham abraham.m...@gmail.com escreveu: On 1/11/13, Oliver Schinagl oliver+l...@schinagl.nl wrote: they can say anything what they want, which makes no sense at all. Well there are a few apps that do use the initial scanfile tree, but do not use any of the dvb-apps. (tvheadend, kaffeine appearantly, i'm guessing VDR and MythTV aswell?) Only tvheadend and kaffeine AFAIK. VDR and MythTV have their own formats. Both mplayer and vlc work with the channels-conf files. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Initial scan files troubles and brainstorming
On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote: On 01/10/2013 09:25 PM, Manu Abraham wrote: Also, purely out of curiousity, how are the scanfiles used during development? The scanfiles what you call them are the configuration files for dvb-apps, rather than purely data files. But you cannot change their format, so what's the point? You can use them from a different directory or system ones... The format can be definitely changed. There's no issue to it. Manu -- 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] Initial scan files troubles and brainstorming
On 01/10/2013 09:38 PM, Manu Abraham wrote: The format can be definitely changed. There's no issue to it. No you cannot. Applications depend on that, it's part of the dvb ABI. If you changed that, you would do the same mistake as Mauro let it flowing through his tree and it was pointed out by Linus in the link you sent... -- js -- 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] Initial scan files troubles and brainstorming
On 01/10/2013 09:41 PM, Jiri Slaby wrote: On 01/10/2013 09:38 PM, Manu Abraham wrote: The format can be definitely changed. There's no issue to it. No you cannot. Applications depend on that, it's part of the dvb ABI. If you changed that, you would do the same mistake as Mauro let it flowing through his tree and it was pointed out by Linus in the link you sent... Id you provide an abstraction library, convert all applications to use that instead of the files, you can change them then. Not any time before. -- js -- 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] Initial scan files troubles and brainstorming
On 1/11/13, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Fri, 11 Jan 2013 01:55:34 +0530 Manu Abraham abraham.m...@gmail.com escreveu: On 1/11/13, Oliver Schinagl oliver+l...@schinagl.nl wrote: they can say anything what they want, which makes no sense at all. Well there are a few apps that do use the initial scanfile tree, but do not use any of the dvb-apps. (tvheadend, kaffeine appearantly, i'm guessing VDR and MythTV aswell?) Only tvheadend and kaffeine AFAIK. VDR and MythTV have their own formats. Both mplayer and vlc work with the channels-conf files. True. they depend upon the output from dvbscan. So when scan changes format, they will also need to update formats to acquire new functionality, else they will be stuck with old functionality. Manu -- 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] Initial scan files troubles and brainstorming
On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote: On 01/10/2013 09:38 PM, Manu Abraham wrote: The format can be definitely changed. There's no issue to it. No you cannot. Applications depend on that, it's part of the dvb ABI. If you changed that, you would do the same mistake as Mauro let it flowing through his tree and it was pointed out by Linus in the link you sent... I understand what you are thinking, but that's not exactly about it. The format can simply be updated by adding newer params to it's end, thus not breaking any of the applications. Manu -- 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] Initial scan files troubles and brainstorming
On 01/10/13 21:32, Manu Abraham wrote: On 1/11/13, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Fri, 11 Jan 2013 00:38:18 +0530 Manu Abraham abraham.m...@gmail.com escreveu: On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote: On 01/10/2013 07:46 PM, Manu Abraham wrote: The scan files and config files are very specific to dvb-apps, some applications do rely on these config files. It doesn't really make sense to have split out config files for these small applications. I don't care where they are, really. However I'm strongly against duplicating them. Feel free to remove the newly created repository, I'll be fine with that. I haven't duplicated anything at all. It is Mauro who has duplicated stuff, by creating a new tree altogether. I only did it by request, and after having some consensus at the ML, and after people explicitly asking me to do that. I even tried to not express my opinion to anybody. But it seems I'm forced by you to give it. So, let it be. The last patches from you there were 11 months ago, and didn't bring any new functionality there... they are just indentation fixes: http://www.linuxtv.org/hg/dvb-apps/ The way you do things, it all ends up like this. https://lkml.org/lkml/2012/12/23/75 That's just mean and below the belt. Anyway, I've brought this issue up on the 18th of oktober 2012 on this mailing list. I had zero replies until early december. Jonathan commented a little and said it was a good idea. Also a few comments about how their patches to scanfiles (data files, facts) where ignored for weeks to an end. Mauro didn't get involved to have everybody that is a maintainer etc get a good chance to respond. The only thing that came from this, is that someone actually stopped maintaining it. Then after everything actually was done (for the better imo), you come in and say it's a bad thing, but dont' really tell us why. Other than it makes development hard for you, which nobody really agree's to with. Anyway, fighting about it won't help anyone, but a good argument as to which procedure is better is good for everyone :) Oliver Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Initial scan files troubles and brainstorming
On 01/10/13 21:41, Jiri Slaby wrote: On 01/10/2013 09:38 PM, Manu Abraham wrote: The format can be definitely changed. There's no issue to it. No you cannot. Applications depend on that, it's part of the dvb ABI. If you changed that, you would do the same mistake as Mauro let it flowing through his tree and it was pointed out by Linus in the link you sent... Actually, there's plenty of apps etc that depend on it. I know some distro's install it into /usr/share/dvb for all to use. I think actually only a very small handfull use their own scanfiles. Very small handfull I belive ;) -- 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] Initial scan files troubles and brainstorming
On 1/11/13, Oliver Schinagl oliver+l...@schinagl.nl wrote: On 01/10/13 21:32, Manu Abraham wrote: On 1/11/13, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Fri, 11 Jan 2013 00:38:18 +0530 Manu Abraham abraham.m...@gmail.com escreveu: On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote: On 01/10/2013 07:46 PM, Manu Abraham wrote: The scan files and config files are very specific to dvb-apps, some applications do rely on these config files. It doesn't really make sense to have split out config files for these small applications. I don't care where they are, really. However I'm strongly against duplicating them. Feel free to remove the newly created repository, I'll be fine with that. I haven't duplicated anything at all. It is Mauro who has duplicated stuff, by creating a new tree altogether. I only did it by request, and after having some consensus at the ML, and after people explicitly asking me to do that. I even tried to not express my opinion to anybody. But it seems I'm forced by you to give it. So, let it be. The last patches from you there were 11 months ago, and didn't bring any new functionality there... they are just indentation fixes: http://www.linuxtv.org/hg/dvb-apps/ The way you do things, it all ends up like this. https://lkml.org/lkml/2012/12/23/75 That's just mean and below the belt. Anyway, I've brought this issue up on the 18th of oktober 2012 on this mailing list. I had zero replies until early december. Jonathan commented a little and said it was a good idea. Also a few comments about how their patches to scanfiles (data files, facts) where ignored for weeks to an end. There was someone who was actively maintaining the config files. One cannot simply state something different unless that person has to say something. In this case as soon as Christoph talked about his stand, I did express my opinion as well. Mauro didn't get involved to have everybody that is a maintainer etc get a good chance to respond. Mauro doesn't do anything wrt dvb-apps. I don't understand, what you are trying to state here. The only thing that came from this, is that someone actually stopped maintaining it. Then after everything actually was done (for the better imo), you come in and say it's a bad thing, but dont' really tell us why. Other than it makes development hard for you, which nobody really agree's to with. At least you should have the courtesy to talk about it with the people who are/were working with it, rather than the people who have no connection to it. I don't want to let go of the efforts that you would like to put into, and hence stated that it would be appreciated if you would maintain the config files within the dvb-apps tree. Just like how you think it is bad for the applications to carry it's own configuration files, I think that it is better for any application to carry it's own configuration files. Manu -- 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] Initial scan files troubles and brainstorming
On 01/10/2013 09:49 PM, Manu Abraham wrote: On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote: On 01/10/2013 09:38 PM, Manu Abraham wrote: The format can be definitely changed. There's no issue to it. No you cannot. Applications depend on that, it's part of the dvb ABI. If you changed that, you would do the same mistake as Mauro let it flowing through his tree and it was pointed out by Linus in the link you sent... I understand what you are thinking, but that's not exactly about it. The format can simply be updated by adding newer params to it's end, thus not breaking any of the applications. OK, but that still does not explain why it is requisite to have the data along with the sources. There is no problem in updating both the files and scandata separately, because it has to be compatible. Also I'm not sure whether adding a column at the end wouldn't break the apps. -- js -- 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] Initial scan files troubles and brainstorming
On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote: On 01/10/2013 09:49 PM, Manu Abraham wrote: On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote: On 01/10/2013 09:38 PM, Manu Abraham wrote: The format can be definitely changed. There's no issue to it. No you cannot. Applications depend on that, it's part of the dvb ABI. If you changed that, you would do the same mistake as Mauro let it flowing through his tree and it was pointed out by Linus in the link you sent... I understand what you are thinking, but that's not exactly about it. The format can simply be updated by adding newer params to it's end, thus not breaking any of the applications. OK, but that still does not explain why it is requisite to have the data along with the sources. There is no problem in updating both the files and scandata separately, because it has to be compatible. scenario1: clone tree 1 make changes update tree 1 scenario2: clone tree 1 make changes update tree 1 clone tree 2 make changes update tree 2 It seems to me that scenario 2 is twice the work, to keep it updated. :-) Simply no reason to do double the work. Also I'm not sure whether adding a column at the end wouldn't break the apps. Don't worry. We have already done that in the past. Manu -- 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: 15a4:1001 fails. (Afatech AF9035)
It works! Thanks Antti. On Wed, Jan 9, 2013 at 8:28 AM, Antti Palosaari cr...@iki.fi wrote: On 01/08/2013 11:54 PM, Eranga Jayasundera wrote: Dear All, I wasn't able to install the driver for Afatech AF9035 (15a4:1001) on my mythbuntu (kernel v3.2.0) box. I used the bellow commands to install the driver. It was compiled and installed without errors. git clone git://linuxtv.org/media_build.git cd media_build ./build sudo make install dmesg output: [ 138.998628] input: Afa Technologies Inc. AF9035A USB Device as /devices/pci:00/:00:1d.0/usb2/2-1/2-1.6/2-1.6.2/2-1.6.2:1.1/input/input13 [ 138.998826] generic-usb 0003:15A4:1001.0004: input,hidraw3: USB HID v1.01 Keyboard [Afa Technologies Inc. AF9035A USB Device] on usb-:00:1d.0-1.6.2/input1 [ 139.015499] usb 2-1.6.2: dvb_usb_v2: found a 'Afatech AF9035 reference design' in cold state [ 139.016174] usbcore: registered new interface driver dvb_usb_af9035 [ 139.018104] usb 2-1.6.2: dvb_usb_v2: Did not find the firmware file 'dvb-usb-af9035-02.fw'. Please see linux/Documentation/dvb/ for more details on firmware-problems. Status -2 [ 139.018109] usb 2-1.6.2: dvb_usb_v2: 'Afatech AF9035 reference design' error while loading driver (-2) [ 139.018116] usb 2-1.6.2: dvb_usb_v2: 'Afatech AF9035 reference design' successfully deinitialized and disconnected [ 180.666110] usb 2-1.6.2: USB disconnect, device number 8 Any thoughts? Firmware is missing. Take one from there: http://palosaari.fi/linux/ and test. You should rename it to the dvb-usb-af9035-02.fw and install location /lib/firmware/ regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Thu Jan 10 19:00:17 CET 2013 git hash:73ec66c000e9816806c7380ca3420f4e0638c40e gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: ERRORS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-i686: WARNINGS linux-3.7-i686: WARNINGS linux-3.8-rc1-i686: OK linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-x86_64: WARNINGS linux-3.7-x86_64: WARNINGS linux-3.8-rc1-x86_64: OK apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Initial scan files troubles and brainstorming
Em Thu, 10 Jan 2013 21:51:29 +0100 Oliver Schinagl oliver+l...@schinagl.nl escreveu: Anyway, fighting about it won't help anyone Agreed. From my side, don't expect further comments. That's hopefully my last email on this thread. Oliver, You owns your time. So, it is really your call. From my side, I appreciate your efforts on keep maintaining it. I don't really care if this is done as a separate tree and/or together with dvb-apps, although, except for the scan files, the dvb-apps seem pretty much orphaned for a long time. So, among other reasons, IMHO it is better to keep it forked. In any case, reimporting the files from an external tree is easy. It is equally easy to add a script at dvb-apps and on other applications that would take a tarball of it and copy the files there. We do that approach on v4l-utils, in order to sync it with kernel headers and kernel IR scancode tables, as we do need new headers there during development, and users do need the very latest IR scancode tables. If you decide to keep it in separate, I recommend you to add there some version schema to make easier for distributions that may want to add a package there, for them to track when this gets updated. Also, just like what we do with media-build's todaytar target, it may also make some sense to have an script running at linuxtv.org that would create daily tarballs when a new commit is merged there, or when a new tag is added. That would help to have scripts at applications to sync with the latest files. If you decide to either drop the tree or to add such tarball script at the server, please ping me. -- 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
[BAD PATCH] saa7134: Add AverMedia Satelllite Hybrid+FM A706
Hello,
this is a bad test patch that adds support for AverMedia Satelllite Hybrid+FM
A706 cards to saa7134.
Working: analog video inputs (composite, s-vhs, analog TV), analog sound
inputs (cinch, TV), analog TV tuner, remote control
Partially working: FM radio - it tunes but detunes to noise after a moment
(might be a bug in tda18271 driver?)
GPIO11 controls 74HC4052 MUX - it's enabled for radio and disabled for TV
in Windows - I did the same and it did not change anything
Untested: DVB-S
There is a hack (added return 0 lines) to disable tda8290 i2c gate.
Is there a way to do this properly?
diff --git a/drivers/media/i2c/ir-kbd-i2c.c b/drivers/media/i2c/ir-kbd-i2c.c
index 08ae067..c1f6e7c 100644
--- a/drivers/media/i2c/ir-kbd-i2c.c
+++ b/drivers/media/i2c/ir-kbd-i2c.c
@@ -230,7 +230,7 @@ static int get_key_avermedia_cardbus(struct IR_i2c *ir,
return 0;
dprintk(1, read key 0x%02x/0x%02x\n, key, keygroup);
- if (keygroup 2 || keygroup 3) {
+ if (keygroup 2 || keygroup 4) {
/* Only a warning */
dprintk(1, warning: invalid key group 0x%02x for key 0x%02x\n,
keygroup, key);
@@ -239,6 +239,10 @@ static int get_key_avermedia_cardbus(struct IR_i2c *ir,
*ir_key = key;
*ir_raw = key;
+ if (!strcmp(ir-ir_codes, RC_MAP_AVERMEDIA_M733A_RM_K6)) {
+ *ir_key |= keygroup 8;
+ *ir_raw |= keygroup 8;
+ }
return 1;
}
@@ -332,6 +336,13 @@ static int ir_probe(struct i2c_client *client, const
struct i2c_device_id *id)
rc_type = RC_BIT_OTHER;
ir_codes= RC_MAP_AVERMEDIA_CARDBUS;
break;
+ case 0x41:
+ name= AVerMedia EM78P153;
+ ir-get_key = get_key_avermedia_cardbus;
+ rc_type = RC_BIT_OTHER;
+ /* RM-KV remote, seems to be same as RM-K6 */
+ ir_codes= RC_MAP_AVERMEDIA_M733A_RM_K6;
+ break;
case 0x71:
name= Hauppauge/Zilog Z8;
ir-get_key = get_key_haup_xvr;
diff --git a/drivers/media/pci/saa7134/saa7134-cards.c
b/drivers/media/pci/saa7134/saa7134-cards.c
index bc08f1d..8b5025d 100644
--- a/drivers/media/pci/saa7134/saa7134-cards.c
+++ b/drivers/media/pci/saa7134/saa7134-cards.c
@@ -5773,6 +5773,36 @@ struct saa7134_board saa7134_boards[] = {
.gpio = 0x000,
},
},
+ [SAA7134_BOARD_AVERMEDIA_A706] = {
+ .name = AverMedia AverTV Satellite Hybrid+FM A706,
+ .audio_clock= 0x00187de7,
+ .tuner_type = TUNER_PHILIPS_TDA8290,
+ .radio_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .radio_addr = ADDR_UNSET,
+ .tuner_config = 0,
+ .gpiomask = 1 11,
+ .mpeg = SAA7134_MPEG_DVB,
+ .inputs = {{
+ .name = name_tv,
+ .vmux = 1,
+ .amux = TV,
+ .tv = 1,
+ }, {
+ .name = name_comp,
+ .vmux = 4,
+ .amux = LINE1,
+ }, {
+ .name = name_svideo,
+ .vmux = 8,
+ .amux = LINE1,
+ } },
+ .radio = {
+ .name = name_radio,
+ .amux = TV,
+ .gpio = 0x800,
+ },
+ },
};
@@ -7020,6 +7050,12 @@ struct pci_device_id saa7134_pci_tbl[] = {
.subdevice= 0x0911,
.driver_data = SAA7134_BOARD_SENSORAY811_911,
}, {
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7133,
+ .subvendor= 0x1461, /* Avermedia Technologies Inc */
+ .subdevice= 0x2055, /* AverTV Satellite Hybrid+FM A706 */
+ .driver_data = SAA7134_BOARD_AVERMEDIA_A706,
+ }, {
/* --- boards without eeprom + subsystem ID --- */
.vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7134,
@@ -7266,6 +7302,7 @@ static int saa7134_tda8290_callback(struct saa7134_dev
*dev,
case SAA7134_BOARD_KWORLD_PCI_SBTVD_FULLSEG:
case SAA7134_BOARD_KWORLD_PC150U:
case SAA7134_BOARD_MAGICPRO_PROHDTV_PRO2:
+ case SAA7134_BOARD_AVERMEDIA_A706:
/* tda8290 + tda18271 */
ret = saa7134_tda8290_18271_callback(dev, command, arg);
break;
@@ -7568,6 +7605,41 @@ int saa7134_board_init1(struct saa7134_dev *dev)
saa_andorl(SAA7134_GPIO_GPMODE0 2, 0x80040100, 0x80040100);
Re: [RFC] Initial scan files troubles and brainstorming
On 01/10/13 23:11, Mauro Carvalho Chehab wrote: Em Thu, 10 Jan 2013 21:51:29 +0100 Oliver Schinagl oliver+l...@schinagl.nl escreveu: Anyway, fighting about it won't help anyone Agreed. From my side, don't expect further comments. That's hopefully my last email on this thread. Oliver, You owns your time. So, it is really your call. Well I did write the initial plea for the seperation. :) From my side, I appreciate your efforts on keep maintaining it. I will do my very best for as long as time permits. I find it personally important that my scanfiles are updated as quickly as possibly and so will also update others as quickly as I can. I don't really care if this is done as a separate tree and/or together with dvb-apps, although, except for the scan files, the dvb-apps seem pretty much orphaned for a long time. So, among other reasons, IMHO it is better to keep it forked. I still think it does make sense for reasons I posted 3 months ago. In any case, reimporting the files from an external tree is easy. It is equally easy to add a script at dvb-apps and on other applications that would take a tarball of it and copy the files there. We do that approach on v4l-utils, in order to sync it with kernel headers and kernel IR scancode tables, as we do need new headers there during development, and users do need the very latest IR scancode tables. If dvb-apps depends on the scanfiles that horribly specifically, then a script to copy over the latest release would be best. If you decide to keep it in separate, I recommend you to add there some version schema to make easier for distributions that may want to add a package there, for them to track when this gets updated. Personally, I'd say date based would be best. After each commit a new tarball should be created. Since it's not 'code' that changes, but factual data, any change warrants a release. So dtv-scan-files-2013011.tar.bz2/xz and is common? if for any reason a second release is needed on the same date ... too bad :p it's extremly unlikly anyway and can be done the next day's date. Or add an index after the date. Also, just like what we do with media-build's todaytar target, it may also make some sense to have an script running at linuxtv.org that would create daily tarballs when a new commit is merged there, or when a new tag is added. That would help to have scripts at applications to sync with the latest files. Well you want to release every commit really, as above stated a commit indicates a change in a transponder. Users of that transponder want to be able to use it asap. If you decide to either drop the tree or to add such tarball script at the server, please ping me. Ping :p -- 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] Initial scan files troubles and brainstorming
On 01/10/13 21:42, Jiri Slaby wrote: On 01/10/2013 09:41 PM, Jiri Slaby wrote: On 01/10/2013 09:38 PM, Manu Abraham wrote: The format can be definitely changed. There's no issue to it. No you cannot. Applications depend on that, it's part of the dvb ABI. If you changed that, you would do the same mistake as Mauro let it flowing through his tree and it was pointed out by Linus in the link you sent... Id you provide an abstraction library, convert all applications to use that instead of the files, you can change them then. Not any time before. Well isn't the scan tables list a database of sorts? It contains the transponder settings for all public accessible transponders. Or should anyway. The format, for now, suffices I'd think. Also, you already convert it sort of. You use dvbscan or whatever scan, to take those files and create channels.conf or what not from it (and search for extra transponders, but having _all_ transponders in the repository would be overkill though I think we do that for dvb-T? So in a sense, it exists as that already :) -- 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: [BUG] crystalhd git.linuxtv.org kernel driver: Crashing again Linux, 3.2, using mozilla flashplugin from adobe
Linux 3.6. was not the cause, it's crashing kernel again: Jan 11 01:37:10 tom3 kernel: [121968.394453] crystalhd :03:00.0: Opening new user[0] handle Jan 11 01:37:13 tom3 kernel: [121971.186506] start_capture: pause_th:12, resume_th:5 Jan 11 01:37:13 tom3 kernel: [121971.273696] crystalhd :03:00.0: [FMT CH] PIB:0 1 420 2 500 1e0 354 0 0 0 Jan 11 01:37:13 tom3 kernel: [121971.675398] crystalhd :03:00.0: MISSING 11 PICTURES Jan 11 01:37:13 tom3 pulseaudio[6153]: ratelimit.c: 63 events suppressed Jan 11 01:37:24 tom3 kernel: [121982.877752] crystalhd :03:00.0: FETCH TIMEOUT Jan 11 01:37:31 tom3 pulseaudio[6153]: ratelimit.c: 258 events suppressed Jan 11 01:37:36 tom3 kernel: [121994.735956] crystalhd :03:00.0: FETCH TIMEOUT Jan 11 01:37:47 tom3 kernel: [122005.765819] BUG: unable to handle kernel NULL pointer dereference at 002c Jan 11 01:37:47 tom3 kernel: [122005.765964] IP: [a046214c] crystalhd_dioq_fetch_wait+0x25c/0x410 [crystalhd] Jan 11 01:37:47 tom3 kernel: [122005.766014] PGD 0 Jan 11 01:37:47 tom3 kernel: [122005.766014] Oops: [#1] PREEMPT SMP Message from syslogd@tom3 at Jan 11 01:37:47 ... kernel:[122005.766014] Oops: [#1] PREEMPT SMP Jan 11 01:37:47 tom3 kernel: [122005.766014] CPU 1 Jan 11 01:37:47 tom3 kernel: [122005.766014] Modules linked in: nfs fscache uinput parport_pc ppdev lp parport bluetooth nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs acpi_cpufreq mperf cpufreq_powersave cpufreq_stats cpufreq_conservative cpufreq_performance cpufreq_ondemand freq_table fuse dm_mod ext3 jbd pciehp arc4 ath5k ath mac80211 snd_hda_codec_analog cfg80211 snd_hda_intel snd_hda_codec snd_usb_audio snd_pcm_oss snd_mixer_oss thinkpad_acpi snd_pcm snd_hwdep snd_usbmidi_lib snd_seq_dummy rfkill snd_seq_oss snd_seq_midi pcmcia snd_rawmidi snd_seq_midi_event snd_seq snd_timer yenta_socket psmouse snd_seq_device pcspkr pcmcia_rsrc usb_storage pcmcia_core serio_raw crystalhd(O) snd i2c_i801 tpm_tis snd_page_alloc soundcore tpm rtc_cmos wmi nvram tpm_bios battery ac evdev processor nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_limit xt_tcpudp iptable_filter ip_tables x_tables ext4 mbcache jbd2 crc16 usbhid hid s g sd_mod crc_t10dif ata_ge Jan 11 01:37:47 tom3 kernel: neric uhci_hcd ata_piix ahci libahci libata atkbd xhci_hcd ehci_hcd thermal e1000e usbcore usb_common [last unloaded: scsi_wait_scan] Jan 11 01:37:47 tom3 kernel: [122005.766014] Jan 11 01:37:47 tom3 kernel: [122005.766014] Pid: 22091, comm: plugin-containe Tainted: G O 3.2.36-dirty #4 LENOVO 7735Y1T/7735Y1T Jan 11 01:37:47 tom3 kernel: [122005.766014] RIP: 0010:[a046214c] [a046214c] crystalhd_dioq_fetch_wait+0x25c/0x410 [crystalhd] Jan 11 01:37:47 tom3 kernel: [122005.766014] RSP: 0018:880005ed3d48 EFLAGS: 00010246 Jan 11 01:37:47 tom3 kernel: [122005.766014] RAX: RBX: 880030785e50 RCX: Jan 11 01:37:47 tom3 kernel: [122005.766014] RDX: 0046 RSI: a04615c3 RDI: 81493e82 Jan 11 01:37:47 tom3 kernel: [122005.766014] RBP: 880005ed3df8 R08: R09: Jan 11 01:37:47 tom3 kernel: [122005.766014] R10: R11: 880030786510 R12: 8800075a2c00 Jan 11 01:37:47 tom3 kernel: [122005.766014] R13: R14: 8800075a2c28 R15: 880030785e50 Jan 11 01:37:47 tom3 kernel: [122005.766014] FS: 7f2fa71fe700() GS:88007f50() knlGS: Jan 11 01:37:47 tom3 kernel: [122005.766014] CS: 0010 DS: ES: CR0: 8005003b Jan 11 01:37:47 tom3 kernel: [122005.766014] CR2: 002c CR3: 63969000 CR4: 06e0 Jan 11 01:37:47 tom3 kernel: [122005.766014] DR0: DR1: DR2: Jan 11 01:37:47 tom3 kernel: [122005.766014] DR3: DR6: 0ff0 DR7: 0400 Jan 11 01:37:47 tom3 kernel: [122005.766014] Process plugin-containe (pid: 22091, threadinfo 880005ed2000, task 880030785e50) Jan 11 01:37:47 tom3 kernel: [122005.766014] Stack: Message from syslogd@tom3 at Jan 11 01:37:47 ... kernel:[122005.766014] Stack: Jan 11 01:37:47 tom3 kernel: [122005.766014] 0327 880030786510 880011f5b100 88007c20e090 Jan 11 01:37:47 tom3 kernel: [122005.766014] 880005ed3e14 880005bde1b0 880005bde000 880030785e50 Jan 11 01:37:47 tom3 kernel: [122005.766014] 8800075a2c60 0001074119c6 880030785e50 Jan 11 01:37:47 tom3 kernel: [122005.766014] Call Trace: Message from syslogd@tom3 at Jan 11 01:37:47 ... kernel:[122005.766014] Call Trace: Jan 11 01:37:47 tom3 kernel: [122005.766014] [810497e0] ? try_to_wake_up+0x260/0x260 Jan 11 01:37:47 tom3 kernel: [122005.766014] [a04637b0] ? bc_cproc_start_capture+0x100/0x100 [crystalhd] Jan 11
Re: [RFC] Initial scan files troubles and brainstorming
On Thu, 10 Jan 2013 21:55:28 +0100, Oliver Schinagl wrote: Actually, there's plenty of apps etc that depend on it. I know some distro's install it into /usr/share/dvb for all to use. I think actually only a very small handfull use their own scanfiles. Very small handfull I belive ;) Indeed. I have just gone to file an Intent To Package bug for the dtv-scan-tables package in Debian, but I noticed that the COPYING and README files were not split out from the dvb-apps tree. Logically it would follow that dtv-scan-tables is also licenced under LGPL, the same as dvb-apps, but this needs to be stated explicitly. This is especially true for distributions which be redistributing dtv-scan-tables. Thanks, Jon signature.asc Description: Digital signature
Re: global mutex in dvb_usercopy (dvbdev.c)
On 10.01.2013 15:25, Mauro Carvalho Chehab wrote: Em Thu, 10 Jan 2013 03:06:51 +0100 thomas schorpp thomas.scho...@gmail.com escreveu: On 09.01.2013 22:30, Nikolaus Schulz wrote: On Tue, Jan 08, 2013 at 12:05:47PM +0530, Soby Mathew wrote: Hi Everyone, I have a doubt regarding about the global mutex lock in dvb_usercopy(drivers/media/dvb-core/dvbdev.c, line 382) . /* call driver */ mutex_lock(dvbdev_mutex); if ((err = func(file, cmd, parg)) == -ENOIOCTLCMD) err = -EINVAL; mutex_unlock(dvbdev_mutex); Why is this mutex needed? When I check similar functions like video_usercopy, this kind of global locking is not present when func() is called. I cannot say anything about video_usercopy(), but as it happens, there's a patch[1] queued for Linux 3.9 that will hopefully replace the mutex in dvb_usercopy() with more fine-grained locking. Nikolaus [1] http://git.linuxtv.org/media_tree.git/commit/30ad64b8ac539459f8975aa186421ef3db0bb5cb Unfortunately, frontend ioctls can be blocked by the frontend thread for several seconds; this leads to unacceptable lock contention. Especially the stv0297 signal locking, as it turned out in situations of bad signal input or my cable providers outtage today it has slowed down dvb_ttpci (notable as OSD- output latency and possibly driver buffer overflows of budget source devices) that much that I had to disable tuning with parm --outputonly in vdr-plugin-dvbsddevice. Can anyone confirm that and have a look at the other frontend drivers for tuners needing as much driver control? I will try to apply the patch manually to Linux 3.2 and check with Latencytop tomorrow. Well, an ioctl's should not block for a long time, if the device is opened with O_NONBLOCK. Unfortunately, not all drivers follow this rule, and blocks. The right fix seem to have a logic at stv0297 that would do the signal locking in background, or to use the already-existent DVB frontend thread, and answering to userspace the last cached result, instead of actively talking with the frontend device driver. Both approaches have advantages and disadvantages. In any case, a change like that at dvb core has the potential of causing troubles to userspace, although I think it is the better thing to do, at the long term. Could You or another with write access commit this in http://git.linuxtv.org/media_build.git if applicable, too, please? I'look into but I'm not yet worked in in kernel threading methods, need to read the O'reilly linux Driver book first about ;-) y tom -- 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] [media] cx231xx: add a missing break statement
My static checker complains about the fall through here. From the context it looks like we should add a break statement. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com --- Untested. diff --git a/drivers/media/usb/cx231xx/cx231xx-video.c b/drivers/media/usb/cx231xx/cx231xx-video.c index 93dfc18..06376d9 100644 --- a/drivers/media/usb/cx231xx/cx231xx-video.c +++ b/drivers/media/usb/cx231xx/cx231xx-video.c @@ -1751,6 +1751,7 @@ static int vidioc_s_register(struct file *file, void *priv, 0x02, (u16)reg-reg, 1, value, 1, 2); + break; case 0x322: ret = cx231xx_write_i2c_master(dev, -- 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
