from:"Devin Heitmueller"

On Mon, Nov 23, 2009 at 9:14 AM, Krzysztof Halasa k...@pm.waw.pl wrote:
 I think this makes a lot of sense.
 But: we don't need a database of RC codes in the kernel (that's a lot of
 data, the user has to select the RC in use anyway so he/she can simply
 provide mapping e.g. RC5keycode).

Just bear in mind that with the current in-kernel code, users do *not
* have to manually select the RC code to use if they are using the
default remote that shipped with the product.  This helps alot for
those unfamiliar with LIRC, since their product works out of the box
with the remote the product came with.  I agree though, that the user
should be able to easily change the RC to be used if he/she decides to
use a remote other than the default.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cx18: Reprise of YUV frame alignment improvements

On Mon, Nov 23, 2009 at 7:12 AM, Andy Walls awa...@radix.net wrote:
 5. If you don't give an MDL back to the firmware, it never uses it
 again.  That's why you see the sweep-up log messages.  As soon as an MDL
 is skipped *on the order of the depth* of q_busy times, when looking for
 the currently DMA_DONE'd MDL, that skipped MDL must have been dropped.
 It is picked up and put back into rotation then.

Perhaps I am misinterpreting the definition of sweep-up in this
context.  Don't the buffers get forcefully returned to the pool at
that point?  If so, why would I see the same error over and over long
after the CPU utilization has dropped back to a reasonable level.

I feel like I must be missing something here.

1.  CPU load goes up (ok)
2.  Packets start to get dropped (expected)
3.  CPU load goes back down (ok)
4.  Packets continue to get dropped and never recycled, even after
minutes of virtually no CPU load?

I can totally appreciate the notion that the video would look choppy
when the system is otherwise under high load, but my expectation would
be that once the load drops back to 0, the video should look fine
(perhaps with some small window of time where it is still recovering).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

On Mon, Nov 23, 2009 at 12:05 PM, James Mastros ja...@mastros.biz wrote:
 2009/11/23 Devin Heitmueller dheitmuel...@kernellabs.com:
 Just bear in mind that with the current in-kernel code, users do *not
 * have to manually select the RC code to use if they are using the
 default remote that shipped with the product.
 This could still happen, if LIRC checks the identifiers of the
 reciving device, and has a database that tells it mappings between
 those devices and the remote controls that shipped with them.
 However, it occours to me that the IR circumstances map pretty well to
 what happens with ps/2 and serial devices now:

 1: There are a variety of drivers for serio computer-side hardware,
 each of which speaks the serio interface to the next-higher level.
 These corrospond to the drivers for IR recievers.
 2: There's a raw serio interface, for those wishing to do strange things.
 3: There's also a variety of things that take data, using the kernel
 serio API, and decode it into input events -- the ps2 keyboard driver,
 the basic mouse driver, the advanced mice drivers.  This is where the
 interface falls down a little bit -- the ps2 keyboard driver is the
 closest analogue to what I'm suggesting.  The ps2 keyboard driver
 creates scancode events, which map nicely to what the keyboard is
 sending -- these are, for ex, rc5 codes.  It will also produce
 key-up/key-down events, if it has a keymap loaded.  (This is the
 difference with a ps2 keyboard -- a ps2 keyboard gets a map assigned
 to it at boottime, so it works out-of-box.  This isn't really possible
 with an IR remote -- though perhaps rc5 is standarized enough, I don't
 think other protocols neccessarly are.)

 Userspace would have to load a keymap; those don't really belong in
 kernel code.  Of course, userspace could look at the device
 identifiers to pick a reasonable default keymap if it's not configured
 to load another, solving the out-of-box experince.

I think perhaps before we go much further into this, we may wish to
come up with a set of use cases and expected behavior.  I worry that
part of the problem here is people are thinking of how their
particular cards behave, and few people have a holistic picture of all
the possible scenarios.  Whatever implementation we come up, we should
be confident that it meets the requirements of *all* the various
hardware implementations.

I will try to draft up some requirements/use cases if people think
this would be worthwhile.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add new TV cards of Beholder

On Mon, Nov 23, 2009 at 4:28 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Hi Dmitri,

 I added this patch, but the driver is essentially broken. It would
 be wonderful if you have some time to fix it.

 Cheers,
 Mauro.

Yeah, I saw his patch and was wondering why on Earth he submitted a
patch adding card support for a completely broken driver.  How could
he have validated the patch is correct?

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

On Mon, Nov 23, 2009 at 4:46 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
 l...@bartelmus.de (Christoph Bartelmus) writes:

 I think we shouldn't at this time worry about IR transmitters.

 Sorry, but I have to disagree strongly.
 Any interface without transmitter support would be absolutely unacceptable
 for many LIRC users, including myself.

 I don't say don't use a transmitter.
 I say the transmitter is not an input device, they are completely
 independent functions. I can't see any reason to try and fit both in the
 same interface - can you?

There is an argument to be made that since it may be desirable for
both IR receivers and transmitters to share the same table of remote
control definitions, it might make sense to at least *consider* how
the IR transmitter interface is going to work, even if it is decided
to not implement such a design in the first revision.

Personally, I would hate to see a situation where we find out that we
took a bad approach because nobody considered what would be required
for IR transmitters to reuse the same remote control definition data.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

On Mon, Nov 23, 2009 at 5:31 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
 Devin Heitmueller dheitmuel...@kernellabs.com writes:

 There is an argument to be made that since it may be desirable for
 both IR receivers and transmitters to share the same table of remote
 control definitions, it might make sense to at least *consider* how
 the IR transmitter interface is going to work, even if it is decided
 to not implement such a design in the first revision.

 Personally, I would hate to see a situation where we find out that we
 took a bad approach because nobody considered what would be required
 for IR transmitters to reuse the same remote control definition data.

 I briefly though about such possibility, but dismissed it with
 assumption that we won't transmit the same codes (including key codes)
 that we receive.

I'm not specifically suggesting that you would want to transmit the
same codes that you receive, but you probably want the database of
remote control definitions to be shared.

For example, you might want the IR receiver to be listening for codes
using the Universal Remote Control XYZ profile and the IR
transmitter pretending to be Cable Company Remote Control ABC when
blasting IR codes to the cable box.  Ideally, there would be a single
shared database of the definitions of the remote controls, regardless
of whether you are IR receiving or transmitting.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cx18: Reprise of YUV frame alignment improvements

2009-11-22 Thread Devin Heitmueller

On Tue, Nov 10, 2009 at 11:31 PM, Andy Walls awa...@radix.net wrote:
 OK, here's my second attempt at getting rid of cx18 YUV frame alignment
 and tearing issues.

        http://linuxtv.org/hg/~awalls/cx18-yuv2

Hi Andy,

I did some testing of your tree, using the following command

mplayer /dev/video32 -demuxer rawvideo -rawvideo w=720:h=480:format=hm12:ntsc

and then in parallel run a series of make commands of the v4l-dvb tree

make -j2  make unload  make -j2  make unload  make -j2  make
unload  make -j2  make unload

I was definitely seeing the corruption by doing this test before your
patches (both frame alignment and colorspace problems as PCI frames
were being dropped).  After your change, I no longer see those
problems.  The picture never became misaligned.  However, it would
appear that some sort of regression may have been introduced with the
buffer handling.

I was seeing a continuous reporting of the following in dmesg, even
*after* I stopped generating the load by running the make commands.

[ 5175.703811] cx18-0: Could not find MDL 106 for stream encoder YUV
[ 5175.737380] cx18-0: Could not find MDL 111 for stream encoder YUV
[ 5175.804317] cx18-0: Skipped encoder YUV, MDL 96, 3 times - it must
have dropped out of rotation
[ 5175.804324] cx18-0: Skipped encoder YUV, MDL 101, 3 times - it must
have dropped out of rotation
[ 5175.904500] cx18-0: Skipped encoder YUV, MDL 96, 2 times - it must
have dropped out of rotation
[ 5176.204507] cx18-0: Skipped encoder YUV, MDL 101, 1 times - it must
have dropped out of rotation
[ 5176.204513] cx18-0: Skipped encoder YUV, MDL 96, 1 times - it must
have dropped out of rotation
[ 5176.204518] cx18-0: Could not find MDL 111 for stream encoder YUV

I would expect to see frame drops while the system was under high
load, but I would expect that the errors would stop once the load fell
back to something reasonable.  However, they continue to accumulate
even after the make commands stop and the only thing running on the
system is mplayer (with a CPU load of around 10%).

I think this tree is definitely on the right track, but it looks like
some edge case has been missed.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PULL request - http://kernellabs.com/hg/~pboettcher/v4l-dvb/

2009-11-20 Thread Devin Heitmueller

On Fri, Nov 20, 2009 at 2:45 AM, Patrick Boettcher
pboettc...@kernellabs.com wrote:
 According to DiBcom's contact at Pinnacle, it was a mistake to add the
 Product IDs with Pinnacle's USB vendor ID and it needed to be replaced.

 I'd be not surprised if that is not correct and that you're right. I will
 fix it and will try to clarify the situation internally.

Given the conflicting information, I have just sent an email to my
PCTV contact asking for clarification.  It's possible I somehow
misinterpreted his previous response.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-staging

2009-11-20 Thread Devin Heitmueller

On Fri, Nov 20, 2009 at 4:45 PM, Hans Verkuil hverk...@xs4all.nl wrote:
 If there are drivers in the staging tree that are so unreliable that they
 can break the hardware, then those should be explicitly disabled, rather
 than disabling all drivers in the staging tree. Or perhaps do not belong
 there at all, or belong under the CONFIG_STAGING_BROKEN option.

 A driver like the go7007 is under active development, and it does work. It
 only needs more cleanup before it can be moved to drivers/media/video, so
 there was no reason that it should be disabled.

 Mauro, what are the risks of always compiling the tm6000 and cx25821
 drivers? Let me know if you think that either one or both should be
 disabled for now and I'll make a patch for it.

I'm certainly much more worried about the tm6000 stuff than the
cx25821, primarily because the cx25821 is pretty rare and the tm6000
is used by several fairly popular consumer products, but is completely
broken.

 I agree that we should be periodically ensuring the modules still
 compile, but I think that by default they should need to be explicitly
 enabled by a developer who knows what he/she is doing and understands
 the ramifications/risks.

 By not compiling you run the very high risk of bit rot: code getting
 seriously out-of-sync with the rest of the tree. Possibly requiring a lot
 of work later. Our tree is primarily for developers, not for end-users. So
 we need to see any code breakages as early as possible.

Sure, in a perfect world that would be true.  In reality though, I'm
confident that a *huge* percentage of people who compile the v4l-dvb
code have absolutely no idea what the hell they are doing.  They are
end-users who just want to see their device work because the changes
haven't made it into their distro yet.

I can certainly appreciate the concerns about the bit-rot issue.  I am
just worried that perhaps we set the bar too low in terms of what got
into staging if it's going to be compiled by default.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PULL request - http://kernellabs.com/hg/~pboettcher/v4l-dvb/

2009-11-19 Thread Devin Heitmueller

On Thu, Nov 19, 2009 at 12:43 PM, Patrick Boettcher
pboettc...@kernellabs.com wrote:
 Hi Mauro,

 can you please pull from

 http://kernellabs.com/hg/~pboettcher/v4l-dvb/

 for

 1) PATCH: better support for INTUIX DVB stick boot
 2) [PATCH] fix genpix driver (no 8psk lock)
 3) Add support for PCTV 74e (Pinnacle) + fix USB vendor IDs
 4) [PATCH] dvb-usb-friio: accept center-shifted frequency

 2 - is fixing a regression in 2.6.32 and should go there if possible. (I
 forgot to set priority: high)

 thanks for pulling,

Patrick,

According to my contact at PCTV, the three devices in question (the
73e/73eSE, 282e/282eNano, and PCTV 74e/74ePico) can have either the
old *or* the new USB ID.  Your patch changes them to the new ID
exclusively (effectively removing entries with the old ID), which will
cause breakage for people who had versions of the board with the old
ID.

Your patch needs to add new entries for the versions of the board with
the new ID.  It cannot replace the old versions.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Details about DVB frontend API

On Tue, Nov 17, 2009 at 5:53 PM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
 We shouldn't write API's thinking on some specific use case or aplication.
 If there's a problem with zap, the fix should be there, not at the kernel.

Your response suggests I must have poorly described the problem.  Zap
is just one example where having an inconsistent view of the various
performance counters is easily visible.  If you're trying to write
something like an application to control antenna orientation, the fact
that you cannot ask for a single view of all counters can be a real
problem.  Having to make separate ioctl calls for each field can cause
real problems here.

I disagree strongly with your assertion that we should not considering
specific use cases when writing an API.  That's *EXACTLY* what you
want to do - when designing an API, you should be asking yourself what
use cases is it actually going to be used for, and strive to build an
API that accommodates all the use cases.  In this case, Manu's
approach provides the ability to get a single consistent view of all
the counters (for those drivers which can support it), which solves a
specific use case that cannot be accomplished with the existing API.
Building abstract APIs without considering all use cases is how we end
up with APIs that nobody uses because they don't actually work in the
real world.

The fact that the existing SNR and strength counters never had their
format explicitly defined is a really good example of how nobody must
have considered how applications would be expected to actually use the
API and represent the information to users in a useful manner.

On the other hand, this issue has been beaten to death so badly and
the existing API has been broken/useless for so long that I have
lowered my expectations to the point where I would accept just about
*any* proposal that actually provides a uniform representation of SNR
across drivers.

(/rant mode off)

 Also, the above mentioned problem can happen even if there's just one API
 call from userspace to kernel or if the driver needs to do separate,
 serialized calls to firmware (or a serialized calculus) to get the
 three measures.

True, the accuracy in which a given driver can provide accurate data
is tied to the quality of the hardware implementation.  However, for
well engineered hardware, Manu's proposed API affords the ability to
accurately report a consistent view of the information.  The existing
implementation restricts all drivers to working as well as the
worst-case hardware implementation.

 For what it's worth, we have solved this problem in hwmon driver the
 following way: we cache related values (read from the same register or
 set of registers) for ~1 second. When user-space requests the
 information, if the cache is fresh it is used, otherwise the cache is
 first refreshed. That way we ensure that data returned to nearby
 user-space calls are taken from the same original register value. One
 advantage is that we thus did not have to map the API to the hardware
 register constraints and thus have the guarantee that all hardware
 designs fit.

 I don't know if a similar logic would help for DVB.

 This could be an alternative, if implemented at the right way. However,
 I suspect that it would be better to do such things at libdvb.

 For example, caching measures for 1 second may be too much, if userspace is
 doing a scan, while, when streaming, this timeout can be fine.

Jean's caching approach for hwmon is fine for something like the
chassis temperature, which doesn't change that rapidly.  However, it's
probably not appropriate for things like SNR and strength counters,
where near real-time feedback can be useful in things like controlling
a rotor.

One more point worth noting - the approach of returning all the
counters in one ioctl can actually be cheaper in terms of the number
of register read operations.  I've seen a number of drivers where we
hit the same register three or four times, since all of various fields
are based on the same register.  Having a single call actually allows
all the duplicate register reads to be eliminated in those cases, the
driver reads the register once and then populates all the fields in
one shot based on the result.

I was actually against Manu's proposal the last time it was put out
there, as I felt just normalizing the existing API would be *good
enough* for the vast majority of applications.  However, if we have
decided to give up on the existing API entirely and write a whole new
API, we might as well do it right this time and build an API that
satisfies all the people who plan to make use of it.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: v4l: Use the video_drvdata function in drivers

On Wed, Nov 18, 2009 at 4:13 AM, Hans Verkuil hverk...@xs4all.nl wrote:
 I agree that it would help to split this patch up. Some cases are trivial,
 so they can be put together in one patch. When things get more complex it
 makes sense to put it in a separate patch for easier reviewing by the
 relevant maintainers.

 This is a very nice cleanup and improves the driver code significantly.
 Especially since so many drivers keep copying the same useless code time
 and again :-(

 Reducing driver code complexity is a very important goal since that is the
 weakest point of many of the existing drivers. But it should be done
 carefully of course and in such a manner that people can review it easily.

Hello Hans,

Thanks for the comments.

Review is good.  Review *and* actually trying the code is better.  If
it comes down to Laurent's time being the constraint, I would rather
see him spending the time setting up a tree with all his proposed
patches and doing a call for testers than cutting up patches so that
maintainers can review and guess whether it's not going to cause
problems in their particular driver (and I say guess here because in
some cases it may fail in non-obvious ways that wouldn't be noticed
without actually trying it).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: v4l: Use the video_drvdata function in drivers

On Wed, Nov 18, 2009 at 4:42 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 I will setup a test tree to help maintainers test the changes. I can split
 some patches if needed, but how would that help exactly ?

Hello Laurent,

In this case, splitting up the patch would just make it easier to
review, and potentially to check in changes for specific bridges as
they are validated (as opposed to all at once).  However, even just
having all your changes in a tree that can be checked out and tested
by users is probably good enough and would still provide
considerable value.

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Details about DVB frontend API

On Wed, Nov 18, 2009 at 9:04 AM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
 Devin Heitmueller wrote:
 On Tue, Nov 17, 2009 at 5:53 PM, Mauro Carvalho Chehab
 mche...@infradead.org wrote:
 We shouldn't write API's thinking on some specific use case or aplication.
 If there's a problem with zap, the fix should be there, not at the kernel.

 Your response suggests I must have poorly described the problem.  Zap
 is just one example where having an inconsistent view of the various
 performance counters is easily visible.  If you're trying to write
 something like an application to control antenna orientation, the fact
 that you cannot ask for a single view of all counters can be a real
 problem.  Having to make separate ioctl calls for each field can cause
 real problems here.

 I disagree strongly with your assertion that we should not considering
 specific use cases when writing an API.

 That's not what I've said (or maybe I haven't said it clear enough).
 I'm saying that we shouldn't look for one particular use case only.
 In other words, the API should cover all use cases that makes sense.

In this case, Manu's
 approach provides the ability to get a single consistent view of all
 the counters (for those drivers which can support it)

 No. To get all counters, you'll need to call 3 ioctls. The status were
 grouped around 3 groups of counters on his proposal. I'm sure Manu has some
 explanation why he thinks that 3 is better then 2 or 4 calls, but the point
 is: should we really group them on a fixed way?

 Btw, by using S2API, we'll break it into different commands. Yet, we can
 call all of them at once, if needed, as the API defines it as:

 struct dtv_property {
        __u32 cmd;
        __u32 reserved[3];
        union {
                __u32 data;
                struct {
                        __u8 data[32];
                        __u32 len;
                        __u32 reserved1[3];
                        void *reserved2;
                } buffer;
        } u;
        int result;
 } __attribute__ ((packed));

 struct dtv_properties {
        __u32 num;
        struct dtv_property *props;
 };

 #define FE_SET_PROPERTY            _IOW('o', 82, struct dtv_properties)
 #define FE_GET_PROPERTY            _IOR('o', 83, struct dtv_properties)

 So, all needed commands can be grouped together to provide an atomic read.

 Also, the above mentioned problem can happen even if there's just one API
 call from userspace to kernel or if the driver needs to do separate,
 serialized calls to firmware (or a serialized calculus) to get the
 three measures.

 True, the accuracy in which a given driver can provide accurate data
 is tied to the quality of the hardware implementation.  However, for
 well engineered hardware, Manu's proposed API affords the ability to
 accurately report a consistent view of the information.  The existing
 implementation restricts all drivers to working as well as the
 worst-case hardware implementation.

 Imagining that some application will need to retrieve all quality indicators
 at the same time, as they were grouped into 3 groups, even on a perfect
 hardware, you won't be able to get all of them at the sime time,
 since you'll need to call 3 ioctls.

 For what it's worth, we have solved this problem in hwmon driver the
 following way: we cache related values (read from the same register or
 set of registers) for ~1 second. When user-space requests the
 information, if the cache is fresh it is used, otherwise the cache is
 first refreshed. That way we ensure that data returned to nearby
 user-space calls are taken from the same original register value. One
 advantage is that we thus did not have to map the API to the hardware
 register constraints and thus have the guarantee that all hardware
 designs fit.

 I don't know if a similar logic would help for DVB.
 This could be an alternative, if implemented at the right way. However,
 I suspect that it would be better to do such things at libdvb.

 For example, caching measures for 1 second may be too much, if userspace is
 doing a scan, while, when streaming, this timeout can be fine.

 Jean's caching approach for hwmon is fine for something like the
 chassis temperature, which doesn't change that rapidly.  However, it's
 probably not appropriate for things like SNR and strength counters,
 where near real-time feedback can be useful in things like controlling
 a rotor.

 I agree.

 Yet, you won't have this feedback in real-time, since calculating
 QoS indicators require some time. So, after moving the rotor, you'll need
 to wait for some time, in order to allow the frontend to recalculate the
 QoS after the movement. There's a problem here, not addressed by none of
 the proposals: when the QoS indicators will reflect the rotor movement?

 If you just read the QoS indicator in a register, you're likely getting a
 cached value from the last time the hardware did the calculus.

 So, if you really need to know the QoS value

Re: Details about DVB frontend API

On Wed, Nov 18, 2009 at 9:04 AM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
 Devin Heitmueller wrote:
 On Tue, Nov 17, 2009 at 5:53 PM, Mauro Carvalho Chehab
 mche...@infradead.org wrote:
 We shouldn't write API's thinking on some specific use case or aplication.
 If there's a problem with zap, the fix should be there, not at the kernel.

 Your response suggests I must have poorly described the problem.  Zap
 is just one example where having an inconsistent view of the various
 performance counters is easily visible.  If you're trying to write
 something like an application to control antenna orientation, the fact
 that you cannot ask for a single view of all counters can be a real
 problem.  Having to make separate ioctl calls for each field can cause
 real problems here.

 I disagree strongly with your assertion that we should not considering
 specific use cases when writing an API.

 That's not what I've said (or maybe I haven't said it clear enough).
 I'm saying that we shouldn't look for one particular use case only.
 In other words, the API should cover all use cases that makes sense.

In this case, Manu's
 approach provides the ability to get a single consistent view of all
 the counters (for those drivers which can support it)

 No. To get all counters, you'll need to call 3 ioctls. The status were
 grouped around 3 groups of counters on his proposal. I'm sure Manu has some
 explanation why he thinks that 3 is better then 2 or 4 calls, but the point
 is: should we really group them on a fixed way?

 Btw, by using S2API, we'll break it into different commands. Yet, we can
 call all of them at once, if needed, as the API defines it as:

 struct dtv_property {
        __u32 cmd;
        __u32 reserved[3];
        union {
                __u32 data;
                struct {
                        __u8 data[32];
                        __u32 len;
                        __u32 reserved1[3];
                        void *reserved2;
                } buffer;
        } u;
        int result;
 } __attribute__ ((packed));

 struct dtv_properties {
        __u32 num;
        struct dtv_property *props;
 };

 #define FE_SET_PROPERTY            _IOW('o', 82, struct dtv_properties)
 #define FE_GET_PROPERTY            _IOR('o', 83, struct dtv_properties)

 So, all needed commands can be grouped together to provide an atomic read.

 Also, the above mentioned problem can happen even if there's just one API
 call from userspace to kernel or if the driver needs to do separate,
 serialized calls to firmware (or a serialized calculus) to get the
 three measures.

 True, the accuracy in which a given driver can provide accurate data
 is tied to the quality of the hardware implementation.  However, for
 well engineered hardware, Manu's proposed API affords the ability to
 accurately report a consistent view of the information.  The existing
 implementation restricts all drivers to working as well as the
 worst-case hardware implementation.

 Imagining that some application will need to retrieve all quality indicators
 at the same time, as they were grouped into 3 groups, even on a perfect
 hardware, you won't be able to get all of them at the sime time,
 since you'll need to call 3 ioctls.

 For what it's worth, we have solved this problem in hwmon driver the
 following way: we cache related values (read from the same register or
 set of registers) for ~1 second. When user-space requests the
 information, if the cache is fresh it is used, otherwise the cache is
 first refreshed. That way we ensure that data returned to nearby
 user-space calls are taken from the same original register value. One
 advantage is that we thus did not have to map the API to the hardware
 register constraints and thus have the guarantee that all hardware
 designs fit.

 I don't know if a similar logic would help for DVB.
 This could be an alternative, if implemented at the right way. However,
 I suspect that it would be better to do such things at libdvb.

 For example, caching measures for 1 second may be too much, if userspace is
 doing a scan, while, when streaming, this timeout can be fine.

 Jean's caching approach for hwmon is fine for something like the
 chassis temperature, which doesn't change that rapidly.  However, it's
 probably not appropriate for things like SNR and strength counters,
 where near real-time feedback can be useful in things like controlling
 a rotor.

 I agree.

 Yet, you won't have this feedback in real-time, since calculating
 QoS indicators require some time. So, after moving the rotor, you'll need
 to wait for some time, in order to allow the frontend to recalculate the
 QoS after the movement. There's a problem here, not addressed by none of
 the proposals: when the QoS indicators will reflect the rotor movement?

 If you just read the QoS indicator in a register, you're likely getting a
 cached value from the last time the hardware did the calculus.

 So, if you really need to know the QoS value

Re: KWorld UB435-Q Support

2009-11-17 Thread Devin Heitmueller

On Tue, Nov 17, 2009 at 9:15 AM, Jarod Wilson ja...@wilsonet.com wrote:
 On Nov 17, 2009, at 1:03 AM, Robert Cicconetti wrote:

 On Tue, Nov 17, 2009 at 12:55 AM, Michael Krufky mkru...@linuxtv.org wrote:
 [ 812.465930] tda18271: performing RF tracking filter calibration
 [ 818.572446] tda18271: RF tracking filter calibration complete
 [ 818.953946] tda18271: performing RF tracking filter calibration
 [ 825.093211] tda18271: RF tracking filter calibration complete


 If you see this happen more than once consecutively, and there is only 1
 silicon tuner present, then it means something very bad is happening, and
 there is a chance of burning out a part.  I still wouldnt not recommend any
 mainline merge until you can prevent this behavior -- I suspect that a GPIO
 reset is being toggled where it shouldnt be, which should be harmless ...
 but until we fix it, we cant be sure what damage might get done...

 The RF tracking filter calibration is a procedure that should only happen
 once while the tuner is powered on -- it should *only* be repeated if the
 tuner indicated that calibration is necessary, and that would only happen
 after a hardware reset.

 This still looks fishy to me...

 Agreed. I did manage to dig into this some more last night, something is 
 definitely still awry. Here's a dmesg dump with some extra debug spew added 
 in key spots:

 ...
 em28xx driver loaded
 tda18271 4-0060: creating new instance
 TDA18271HD/C2 detected @ 4-0060
 tda18271: R_EP1 is 0xce
 cal is not initialized (cal_initialized=false)...
 tda18271: performing RF tracking filter calibration
 tda18271: RF tracking filter calibration complete (0xde)
 DVB: registering new adapter (em28xx #0)
 DVB: registering adapter 0 frontend 0 (LG Electronics LGDT3304 VSB/QAM 
 Frontend)...
 em28xx #0: Successfully loaded em28xx-dvb
 Em28xx: Initialized (Em28xx dvb Extension) extension

 1st tuning attempt

 tda18271: R_EP1 is 0x00
 cal is not initialized (cal_initialized=true)...
 tda18271: performing RF tracking filter calibration
 tda18271: RF tracking filter calibration complete (0x00)
 tda18271: R_EP1 is 0x00
 cal is not initialized (cal_initialized=true)...
 tda18271: performing RF tracking filter calibration
 tda18271: RF tracking filter calibration complete (0x00)

 2nd tuning attempt

 tda18271: R_EP1 is 0x00
 cal is not initialized (cal_initialized=true)...
 tda18271: performing RF tracking filter calibration
 tda18271: RF tracking filter calibration complete (0x00)
 tda18271: R_EP1 is 0x00
 cal is not initialized (cal_initialized=true)...
 tda18271: performing RF tracking filter calibration
 tda18271: RF tracking filter calibration complete (0x00)

 I'll try tweaking the GPIO reset mask and whatnot, definitely does seem like 
 something's getting reset that shouldn't, because you can clearly see that 
 cal *was* initialized, then R_EP1 got zeroed out.

 It happened at every tuning operation, and made mythfrontend unhappy
 (unable to tune after the first channel). I disabled the check for
 RF_CAL_OK which triggered the recalibration, and mythfrontend worked.

 Yeah, tuning is much quicker here if I skip that check as well, but its 
 definitely not the proper fix.

 The stick has been plugged in for a few months, so presumably would've
 caught on fire by now if it was going to. It would be nice if the
 tuning delay went away, though.. it still takes ~6 seconds to switch
 frequencies.

 Wait, it still takes that long with the check gone? I didn't poke for very 
 long with the check disabled, mostly focusing on trying to figure out why 
 things are going haywire.

 I have not yet compiled and tested the lastest patches from Jarod.

 Really shouldn't be any difference from what you've got, they're just rebased 
 to the latest v4l-dvb tree.

Hey Jarod,

I haven't seen your exact GPIO config but I noticed something
recently:  the em28xx driver runs the dvb_gpio sequence whenever
starting streaming, not just whenever opening the DVB frontend.  This
means that if your dvb_gpio definition strobes the tda18271 reset (as
opposed to just taking it out of reset), then the chip will get reset
whenever the streaming is started (a real problem if multiple tuning
attempts are performed without closing the frontend first).

Mauro seems to think this is intended behavior, although I cannot see
how this could possibly be correct, especially since the .init()
callback is not called in that case.  I setup a tree to remove the
call, but never got far enough into the testing to confirm whether it
broke any improperly configured boards depending on the incorrect
behavior.

As a test, you might want to check your dvb_gpio config and see if you
are pulling anything low and then high, and just remove the line that
sets the pin low and see if the recalibration still occurs.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to

Re: Details about DVB frontend API

2009-11-17 Thread Devin Heitmueller

On Tue, Nov 17, 2009 at 2:46 PM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
 I don't like the idea of creating structs grouping those parameters. While for
 certain devices this may mean a more direct approach, for others, this may
 not make sense, due to the way their API's were implemented (for example,
 devices with firmware may need several calls to get all those info).

There is some value in providing grouping the results in a single
request - in many cases the data is based off of the same internal
registers, and Manu's proposed approach allows for a more atomic
response.  The fact that we currently do the status, SNR, strength,
and UNC/BER in separate calls is one reason that people sometimes see
inconsistent results in the output of tools like zap.  As an example,
they can see lines in the zap output where the lock is lost but SNR
appears fine.

In the case where the driver servicing the query needs to do three
calls, it could be slightly more expensive, but only if we believe
that it is commonplace to ask for a subset of the stats.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] em28xx: fix for Dikom DK300 hybrid USB tuner (aka Kworld VS-DVB-T 323UR ) (digital mode)

2009-11-16 Thread Devin Heitmueller

On Mon, Nov 16, 2009 at 3:38 PM, andrea.amoros...@gmail.com
andrea.amoros...@gmail.com wrote:
 The usb is the following:
 Bus 002 Device 010: ID eb1a:e312 eMPIA Technology, Inc.
 (I don't remember what it was previously, but it seems wrong how can I be
 sure about that?).
 I have put back the driver to the original state, but still it doesn't work.
 Did I have to reprogram the eprom? If so, it is possible via usb?
 Thank you,
 Andrea

Well, according to em28xx-cards.c, the EM2882_BOARD_KWORLD_VS_DVBT is
eb1a:e323.  You can probably just the USB_DEVICE() entry to say e312,
and that will allow the driver to load (at which point you can then
reprogram the eeprom back to its previous state).

I assume that when you used the eeprom rewrite script, that you used a
copy of *YOUR* dmesg output from before the problem?  You cannot use
someone else's dmesg output, as that may not actually match your
device.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] em28xx: fix for Dikom DK300 hybrid USB tuner (aka Kworld VS-DVB-T 323UR ) (digital mode)

2009-11-16 Thread Devin Heitmueller

On Mon, Nov 16, 2009 at 3:49 PM, andrea.amoros...@gmail.com
andrea.amoros...@gmail.com wrote:
 The usb is the following:
 Bus 002 Device 010: ID eb1a:e312 eMPIA Technology, Inc.
 (I don't remember what it was previously, but it seems wrong how can I be
 sure about that?).
 I have put back the driver to the original state, but still it doesn't work.
 Did I have to reprogram the eprom? If so, it is possible via usb?
 Thank you,
 Andrea

 PS I've found an old dmesg.
 The USB ID is wrong! The old one was eb1a:e323

Ok, so that confirms that indeed the eeprom was corrupted.  I would
suggest you hack the USB_DEVICE() entry in em28xx-cards.c to be
eb1a:e312.  This will allow the driver to load and the i2c device to
be setup.  Then use the eeprom repair script to rewrite the eeprom.
At that point you should be able to remove the hack, because the USB
ID will be back to eb1a:e323.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-dvb] Video lost after OS upgrade

2009-11-16 Thread Devin Heitmueller

On Mon, Nov 16, 2009 at 10:29 PM,  guzows...@linuxmail.org wrote:
 Hello all,

 I was happily watching TV with mplayer from my cable set-top box via a
 Pinnacle HDTV Pro USB Stick and Ubuntu 9.04.

 The command I was using and which worked was/is:

 mplayer -vo xv tv:// -tv
 driver=v4l2:alsa:immediatemode=0:adevice=hw.1,0:norm=ntsc:chanlist=us-cable:channel=3

 After ugrading to Ubuntu 9.10, when I launch mplayer with this command, I
 get an empty black window with no video or audio.  Any ideas and/or  help
 would be greatly appreciated.

 Paul in NW FL, USA

Hello Paul,

I assume you are talking about the 800e version of the HD Pro Stick
(USB ID 2304:0227), right?

http://linuxtv.org/wiki/index.php/Pinnacle_PCTV_HD_Pro_Stick_%28800e%29

That device should continue to work under 9.10.  I noticed that your
mplayer line did not specify which input to use.  Have you tried
connecting something to the s-video or composite to see if you start
getting a picture?  Typically you need to explicitly tell mplayer
which input to use (I don't have the exact syntax in front of me, but
it's in the mplayer man page).

Also, you have the xc3028 firmware installed, right?  Are you seeing
any errors in your dmesg output?

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PULL] http://www.kernellabs.com/hg/~dheitmueller/misc-fixes-4

2009-11-15 Thread Devin Heitmueller

Hello Mauro,

Please pull from
http://www.kernellabs.com/hg/~dheitmueller/misc-fixes-4 for the
following:

cxusb: Fix hang on DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1)

Thanks,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: I found I bug in tvtime, where do I report it?

2009-11-13 Thread Devin Heitmueller

On Fri, Nov 13, 2009 at 9:43 AM, Magnus Alm magnus@gmail.com wrote:
 Hi!

 If this is the right place, I can as well try to describe it now.
 (And I hope I makes sense.)

 The bug is about the Enable/Disable signal detection.

 As it is now in  videoinput.c:

 int videoinput_check_for_signal( videoinput_t *vidin, int check_freq_present )
 {
    if(  videoinput_freq_present( vidin ) || !check_freq_present ) {
        switch( vidin-cur_tuner_state ) {
        case TUNER_STATE_NO_SIGNAL:


 Should be:

 int videoinput_check_for_signal( videoinput_t *vidin, int check_freq_present )
 {
    if( !check_freq_present || videoinput_freq_present( vidin )) {
        switch( vidin-cur_tuner_state ) {
        case TUNER_STATE_NO_SIGNAL:

 So just switch place for videoinput_freq_present( vidin ) and
 !check_freq_present so it actually cares if you disable signal
 detection.

 With this change, disabling signal detection will remove the frame
 drops I have in tvtime.


 Cheers, have a nice weekend.
 Magnus Alm

From a maintainership standpoint, tvtime is effectively dead.  I've
been planning on setting up a new hg tree over at
http://kernellabs.com/hg since I have some patches I want to get in
there too.  I can add yours to the series.

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-dvb] Organizing ALL device data in linuxtv wiki

2009-11-13 Thread Devin Heitmueller

On Fri, Nov 13, 2009 at 11:38 AM, Jan Hoogenraad
jan-conceptro...@hoogenraad.net wrote:
 Would it be possible to store this information in the CODE archives, and
 extract it from there ?
 Right now, I end up putting essentially the same information into structures
 in the driver and into documentation.
 This is hard to keep synchronised.

 Basic information like device IDs, vendors, demod types, tuners, etc is
 already in place in the driver codes.

 Getting data from the hg archives (including development branches) sounds
 like a cleaner solution.

The challenge you run into there is that every driver organizes its
table of products differently, and the driver source code does not
expose what features the device supports in any easily easily parsed
manner.  Also, it does not indicate what the hardware supports which
is not supported by the Linux driver.

So for example, you can have a hybrid USB device that supports
ATSC/QAM and analog NTSC.  The driver won't really tell you these
things, nor will it tell you that the hardware also supports IR but
the Linux driver does not.

It's one of those ideas that sounds reasonable until you look at how
the actual code defines devices.

Devin


-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How can I create a patch?

2009-11-12 Thread Devin Heitmueller

On Thu, Nov 12, 2009 at 5:24 PM,  xwang1...@email.it wrote:
 Hi to all,
 I've a usb hybrid tuner which does not work with the main v4l driver.
 I've found a way to use it modifying some lines in the em28xx-dvb.c and
 em28xx-cards.c files (thanks to Dainius Ridzevicius).
 Can someone explain me how to create a diff between the main v4l
 driver and the patched version so that I can share it in order to have it
 merged upstream?
 Thank you,
 Xwang
 --
 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


Run the following:

hg diff  output.patch

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [XC3028] Terretec Cinergy T XS wrong firmware xc3028-v27.fw

2009-11-12 Thread Devin Heitmueller

On Thu, Nov 12, 2009 at 6:33 PM, Florent NOUVELLON
flonouvel...@gmail.com wrote:
 Sorry about that mistake... That was an em28xx-new trick.

 So my question is simply :
 Do you know how to disable compiling some drivers on v4l-dvb for faster
 compiling ?

Well, I typically disable firedtv because of the Ubuntu bug.  I
wouldn't recommend compiling out drivers to improve compile
performance (it's just too easy to screw up because of non-obvious
dependencies).  If you are recompiling regularly, I would suggest
installing ccache instead.

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [XC3028] Terretec Cinergy T XS wrong firmware xc3028-v27.fw

2009-11-10 Thread Devin Heitmueller

On Tue, Nov 10, 2009 at 4:39 AM, Valerio Bontempi
valerio.bonte...@gmail.com wrote:
 Yes I rebooted the system after compiling and installing through 'make
 install' last v4l-dvb source, but with no luck, /dev/dvb device is
 still not present.

 Attached you can find the full dmesg, since system boot

 Thanks a lot again.


 P.s. Sorry for top posting, it's gmail0s default and sometimes I forget.

Hello Valerio,

Now that I have taken another look at the dmesg output, I see that
this device is 0ccd:0043 and *not* 0ccd:0042.  This prompted me to
take another look at the driver, and indeed that board is not
presently supported.  It's the DVB only version of the board (as
opposed to the hybrid).

I can probably make it work, but it's a rather old board and not
terribly high on my list of priorities.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [XC3028] Terretec Cinergy T XS wrong firmware xc3028-v27.fw

2009-11-10 Thread Devin Heitmueller

On Tue, Nov 10, 2009 at 10:49 AM, Valerio Bontempi
valerio.bonte...@gmail.com wrote:
 Hi Devin,

 I feared about that
 So, in this moment my only possibilities available to make it work are:
 - use an older kernel (=2.6.27) to compile successfully em28xx-new
 (maybe it could be better to use older linux distro)
 - make em28xx-new to compile on 2.6.31 kernel version
 - wait for device support on next kernel releases

 I have good programming knowledge, but few with C and driver
 programming, so if you can suggest me how can I modify em28xx-new
 sources to make them work on 2.6.31, then I can try to adjust them and
 then make this driver available just waiting for kernel support.

In theory you just need your board profile properly defined in
em28xx-cards.c and em28xx-dvb.c.  If I were going to choose between
trying to make the old em28xx-new compile under the current kernel,
and adding the 10-15 lines of code to the in-kernel em28xx driver, I
would probably consider choosing the latter (and then feel free to
submit the patch to be merged upstream).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Terratec Cinergy Hybrid T USB XS FM and 2.6.31 : no more support ?

2009-11-09 Thread Devin Heitmueller

On Mon, Nov 9, 2009 at 2:13 PM, Florent nouvellon
flonouvel...@gmail.com wrote:
 Hi,

 Terratec Cinergy Hybrid T USB XS FM is fully supported by em28xx-new
 project, but em28xx-new project is no more supported and not compatible with
 kernel 2.6.31.
 Is this hardware still supported ?

This device has never been supported in the mainline kernel.  I don't
foresee it getting implemented anytime soon since I don't have a board
to debug/test with (and since this is the first instance where we
would be doing xc5000 on em28xx, I wanted to have a unit I could debug
personally).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [XC3028] Terretec Cinergy T XS wrong firmware xc3028-v27.fw

2009-11-09 Thread Devin Heitmueller

On Mon, Nov 9, 2009 at 6:41 PM, Robert Lowery rglow...@exemail.com.au wrote:
 Although the xc3028-v27.fw generated from
 HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip using the above process works fine
 for me, the firmware is a couple of years old now and I can't help
 wondering if there might be a newer version in the latest Windows drivers
 out there containing performance or stability fixes it in.

 Do you think it would be worthwhile extracting a newer version of firmware?

That is the latest version of the firmware for that chip.  Xceive has
not updated it since then, given that they are focusing on newer
products like the xc5000 and xc3028L.

Your problem has nothing to do with the firmware.  The issue is the
driver support for your particular device was only added recently
(after Ubuntu did their kernel freeze for Karmic).  The work
associated with adding support for devices is nontrivial, and I
typically only do it when people report that their device needs
support.

Devin


-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bisected regression in tuner-xc2028 on DVICO dual digital 4

On Sat, Nov 7, 2009 at 9:40 PM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
 Hello Vince,

 I think the next step at this point is for you to definitively find a
 use case that does not work with the latest v4l-dvb tip and Robert's
 patch, and include exactly what kernel you tested with and which board
 is having the problem (including the PCI or USB ID).

 At this point, your description seems a bit vague in terms of what is
 working and what is not.  If you do the additional testing to narrow
 down specifically the failure case you are experiencing, I will see
 what I can do.

 That said, I'm preparing a tree with Robert's patch since I am pretty
 confident at least his particular problem is now addressed.

 Thanks,

 Devin

Robert,

FYI:  this has been merged into my local tree (after fixing some
whitespace problems introduced by the inlining of the patch into the
email).  I'll issue a PULL request tonight.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bisected regression in tuner-xc2028 on DVICO dual digital 4

On Sun, Nov 8, 2009 at 6:46 PM, Barry Williams bazzaw...@gmail.com wrote:
 Where would I find your local tree as I can't seem to get the patch to
 apply and I would like to take advantage of this patch asap.
 Thanks
 Barry

I pushed out my tree with the fix:

http://kernellabs.com/hg/~dheitmueller/misc-fixes-4

I haven't issued a PULL yet to put it into the mainline since I have a
couple of other things pending.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bisected regression in tuner-xc2028 on DVICO dual digital 4

On Sun, Nov 8, 2009 at 8:43 PM, Barry Williams bazzaw...@gmail.com wrote:
 Hi Devin
 I tried your tree and I seem to get the same problem on one box I get
 the flood of 'dvb-usb: bulk message failed: -110 (1/0'.
snip

Can you please confirm the USB ID of the board you are having the
problem with (by running lsusb from a terminal window)?

Thanks,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bisected regression in tuner-xc2028 on DVICO dual digital 4

On Sun, Nov 8, 2009 at 9:01 PM, Barry Williams bazzaw...@gmail.com wrote:
 On the first box I have
 Bus 003 Device 003: ID 0fe9:db98 DVICO
 Bus 003 Device 002: ID 0fe9:db98 DVICO

 on the second
 Bus 001 Device 003: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
 (ZL10353+xc2028/xc3028) (initialized)
 Bus 001 Device 002: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
 (ZL10353+xc2028/xc3028) (initialized)

And on which of the two systems are you still having the tuning
problem with?  Also, did you reboot after you installed the patch?

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bisected regression in tuner-xc2028 on DVICO dual digital 4

On Sun, Nov 8, 2009 at 9:54 PM, Robert Lowery rglow...@exemail.com.au wrote:
 On Mon, Nov 9, 2009 at 12:22 PM, Devin Heitmueller
 dheitmuel...@kernellabs.com wrote:
 On Sun, Nov 8, 2009 at 8:43 PM, Barry Williams bazzaw...@gmail.com
 wrote:
 Hi Devin
 I tried your tree and I seem to get the same problem on one box I get
 the flood of 'dvb-usb: bulk message failed: -110 (1/0'.
 snip

 Can you please confirm the USB ID of the board you are having the
 problem with (by running lsusb from a terminal window)?

 Thanks,

 Devin
 --


 On the first box I have
 Bus 003 Device 003: ID 0fe9:db98 DVICO
 Bus 003 Device 002: ID 0fe9:db98 DVICO

 on the second
 Bus 001 Device 003: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
 (ZL10353+xc2028/xc3028) (initialized)
 Bus 001 Device 002: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
 (ZL10353+xc2028/xc3028) (initialized)
 --
 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

 Barry,

 I have the Dual Digital 4 rev1 card which corresponds to the 0fe9:db78
 card.  0fe9:db98 is the Dual Digital 4 rev2 card which I believe uses
 completely different hardware and it's behavior is unchanged by my patch
 which only targets the rev1 card.

 I suspect the problems you are still reporting are from the different
 cards, completely unrelated to my fix.

 Would you be able to retest after removing the rev2 cards from the machine?

 -Rob

Robert,

It's worth noting that the introduction of the i2c gate stuff in the
zl10353 broke essentially *all* cards that use that demod except for
the one that prompted the change.  I've been incrementally going
through the cards and fixing it as people report it.

Since both of his cards use the zl10353, it wouldn't surprise me that
his other board is broken for the same reason (which would require an
additional patch).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bisected regression in tuner-xc2028 on DVICO dual digital 4

On Sun, Nov 8, 2009 at 10:58 PM, Barry Williams bazzaw...@gmail.com wrote:
 Hi Devin
 I did not reboot after installing the patch somehow I thought simply
 removing the module (as I had done to restore some stability to my
 system) and reloading the module after the patch would be all I need.
 Well I learned that is not the case my apologies for not trying that
 first. So your tree fixed my second system with the rev 1 tuner.
 However my first system with the rev 2 card while now stable with your
 tree will not tune.
 Barry

Ok, good.  So now we just need to nail down why the 0fe9:db98 board
doesn't work.  Fortunately, I think I know what that bug is too.

Try this:

1.  Reboot the system.
2.  Perform a single tuning attempt.
3.  Send the full dmesg output starting at the time the box is booted.

If you're lucky, it's the issue I think it is, which will result in a
one-line patch.

Thanks,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bisected regression in tuner-xc2028 on DVICO dual digital 4

On Sun, Nov 8, 2009 at 11:35 PM, Barry Williams bazzaw...@gmail.com wrote:
 Devin
 Attached is the output from dmesg, I hope you're right
 Thanks
 Barry

Ah, based on the dmesg I can see it wasn't what I thought it was (I
saw it was dib7000 and improperly assumed it had an xc3028 tuner like
the rev1 board does).

You should probably start a new thread on the mailing list regarding
the problems you are having with this tuner.  And you will probably
need to bisect the v4l-dvb tree and see when the breakage was
introduced.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx based USB Hybrid (Analog DVB-T) TV Tuner not supported

On Sat, Nov 7, 2009 at 7:35 AM, Magnus Alm magnus@gmail.com wrote:
 Hi

 I read some where that trying different card types for a DVB tuner can
 potentially cause damage to them.

 You are probably right about the firmare.
 Do you have a link to the manufacture of your stick?
 I tried to google the name of it but couldn't found an exact match.

 The EM2881_BOARD_PINNACLE_HYBRID_PRO uses it's XC3028 to getter with a
 ZARLINK456
 as you can see from the following line in em28xx-cards.c

 case EM2881_BOARD_PINNACLE_HYBRID_PRO:
                ctl-demod = XC3028_FE_ZARLINK456;
                break;

 It is probably not compliant with your  Zarlink MT352.

 There is a mt352 module tho, but I guess it doesn't get loaded when
 you plug your stick in.

 I'll pooke around a bit.

 PS
 Use the reply all, so others can see your mails, since I'm probably
 one of the least competent guys/gals on this mailing list.
 DS



 2009/11/7 Johan Mutsaerts joh...@gmail.com:
 Hi Magnus,

 Thanks for a quick reply. Here is some more detailed information:

 My USB device ID is 0xeb1a:0x2881 it is eMPIA based.

 These are the components inside
 - Empia EM2880
 - Texas Instruments 5150AM1
 - XCeive XC3028
 - Empia EMP202
 - Zarlink MT352

 Difficult for me to get to the windows stuff

 No /dev/dvb/ is generated ? Could it have something to do with no 
 Firmware ?

 I found my device to be quite similar to the Pinnacle Hybrid Pro so I tried
 sudo rmmod em28xx-dvb
 sudo rmmod em28xx-alsa
 sudo rmmod em28xx
 sudo modprobe em28xx card=53 and card=56
 sudo modprobe em28xx-alsa
 sudo modprobe em28xx-dvb
 However with not much success.
 Card=53 cased MeTV to see a tuner but no channels could be found

 TIA for any assistance you can provide.

 Best Regards,
 Johan

 2009/11/7 Magnus Alm magnus@gmail.com:
 Hi!

 The dmesg didn't reveal what tuner your stick/card has, it's probably
 a XC2028/XC3028 or something like that.
 Easiest way to find out would be if you could open the cover and have
 a look inside.

 If you have access to windows and the pvr program that came with the
 tuner you could do a usb-sniff.

 http://www.pcausa.com/Utilities/UsbSnoop/
 or
 http://benoit.papillault.free.fr/usbsnoop/

 Switch between different inputs while doing the log, like dvb,
 analog and if it has svideo/composite input.

 copy the windows log to unix and parse the output with parser.pl (I've
 added is as an attachment.)
 I think there is a new parser somewhere, but I forgot the name of it.

 I'm also not sure how I used it, but I think it was like this: perl
 parser.pl  your_windows_log  parsed_log
 That log is needed to  find out what gpio your tuner needs for
 different settings.

 Don't be scared of the size of the windows log, it gets large, often a
 few hundred MB.
 The parsed log is much smaller,  a few hundred KB.

 That is all I can think about atm.

 /Magnus Alm


 2009/11/6 Johan Mutsaerts joh...@gmail.com:
 Hi,

 I have an iDream UTVHYL2 USB TV Tuner (with IR remote control) that I
 cannot get to work with Ubuntu (9.04, 2.6.28-16). I have successfully
 compiled and installed the em28xx-new driver from linuxtv.org. No
 /dev/dvb/adapter... is created and that is where it ends for me know.
 MyTV claims no adapter is detected.

 I have attached the output of lsusb and dmesg as requested...

 Please let me know what more I can do and what exactly it is you can do ?

 Thanks in advance and
 Best Regards,
 Johan (Belgium)

I'm away from Internet access so I can't write an extended answer, but
I can tell you that XC3028_FE_ZARLINK456 is appropriate for both the
zarlink zl10353 and m352.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx based USB Hybrid (Analog DVB-T) TV Tuner not supported

On Sat, Nov 7, 2009 at 10:31 AM, Johan Mutsaerts joh...@gmail.com wrote:
 Hi,

 Something caught my eye while examining em28xx-dvb.c

 #include mt352.h
 #include mt352_priv.h /* FIXME */

 What's the FIXME about ? Could it be a clue ?

 What do you suggest I try/text ?

Please don't top post.

No, I just put that FIXME there because the driver really shouldn't be
using the private headers.

I'm actually not in front of the code right now, so I cannot provide
any recommendations.  I will be back home on Sunday though and at that
point I can take a look at the code and offer some suggestions.

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners

On Sat, Nov 7, 2009 at 8:37 PM, Andy Walls awa...@radix.net wrote:
 On Sat, 2009-11-07 at 21:47 +, Ben Hutchings wrote:
 Signed-off-by: Ben Hutchings b...@decadent.org.uk
 ---
 I'm not really sure whether it's better to do this in the drivers which
 specify which firmware file to use, or just once in the xc2028 tuner
 driver.  Your call.

 Ben.

 Ben,

 I would suspect it's better left in the xc2028 tuner driver module.

 Rationale:

 a. it will be consistent with other modules like the cx25840 module.
 ivtv and cx23885 load the cx25840 module yet the MODULE_FIRMWARE
 advertisement for the CX2584[0123] or CX2388[578] A/V core firmware is
 in the cx25840 module.

 b. not every ivtv or cx18 supported TV card, for example, needs the
 XCeive tuner chip firmware, so it's not a strict requirement for those
 modules.  It is a strict(-er) requirement for the xc2028 module.

 My $0.02

 Regards,
 Andy

It's not clear to me what this MODULE_FIRMWARE is going to be used
for, but if it's for some sort of module dependency system, then it
definitely should *not* be a dependency for em28xx.  There are lots of
em28xx based devices that do not use the xc3028, and those users
should not be expected to go out and find/extract the firmware for
some tuner they don't have.

Also, how does this approach handle the situation where there are two
different possible firmwares depending on the card using the firmware.
 As in the example above, you the xc3028 can require either the xc3028
or xc3028L firmware depending on the board they have.  Does this
change now result in both firmware images being required?

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bisected regression in tuner-xc2028 on DVICO dual digital 4

On Sat, Nov 7, 2009 at 6:28 AM, Vincent McIntyre
vincent.mcint...@gmail.com wrote:
 Hi Devin

 please confirm exactly which of your boards is not working.

 Sorry for being unclear.

 I have three test setups I am working with, all on the same computer.
 1. Ubuntu Hardy, kernel 2.6.24-23-rt and drivers from v4l-dvb tip.
 2. Ubuntu Karmic, kernel 2.6.31-14-generic, stock Ubuntu drivers.
 3. Ubuntu Karmic, kernel 2.6.31-14-generic, v4l-dvb tip.

 Setups 2  3 are the same install, on a separate hard disk from setup 1.
 I change between 2  3 by installing the v4l modules or restoring the
 ubuntu stuff from backup. (rsync -av --delete).

 The computer has two DVB-T cards.

 First device is the same as Robert's, I believe. It has two tuners. lsusb 
 gives:
 Bus 003 Device 003: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
 (ZL10353+xc2028/xc3028) (initialized)
 Bus 003 Device 002: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
 (ZL10353+xc2028/xc3028) (initialized)
 I have a 'rev1' version of this board.


 Second device is DViCO FusionHDTV Dual Digital Express, a PCIe card
 based on cx23885[1] It also has two tuners. lspci gives:
 04:00.0 Multimedia video controller [0400]: Conexant Systems, Inc.
 CX23885 PCI Video and Audio Decoder [14f1:8852] (rev 02)
        Subsystem: DViCO Corporation Device [18ac:db78]
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
 Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
 TAbort- MAbort- SERR- PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 19
        Region 0: Memory at 9000 (64-bit, non-prefetchable) [size=2M]
        Capabilities: access denied
        Kernel driver in use: cx23885
        Kernel modules: cx23885

 With Robert's patch compiled in:
  * On setup 1
  I am able to tune both cards and there are no errors from the cxusb module
   or dvb-usb anymore.
   I tested each of the four tuners, by running dvbscan with
 appropriate arguments to
   select the right /dev/dvb/adapterN.

   I just realised I should probably revert the patch and check which
 tuners show the
   original problem. Before I was taking the default choice (adapter0,
 I think) which is
    one of lhe Dual Digital 4 tuners.

  * I have yet to test setup 2,
   I have built the patched kernel module but the box is back 'in
 production' right now.
   I plan to test tomorrow.

  * On setup 3. I attempted to tune using dvbscan, w_scan and vlc.
   Again, I was not specific about which tuner the applications should use.
   So to answer your question, I think it is the lsusb id 0fe9:db78
 that is unable to tune.
   I will check the tuners individually, tomorrow.

   My impression was that the failures were because of API differences
 between the
   applications (all provided as part of the ubuntu install) and the
 V4L modules. I have
   not tried to build v4l-apps from the mercurial tree.

 So, I hope this makes things clearer. Happy to run tests if you have
 any time to look at this.

Hello Vince,

I think the next step at this point is for you to definitively find a
use case that does not work with the latest v4l-dvb tip and Robert's
patch, and include exactly what kernel you tested with and which board
is having the problem (including the PCI or USB ID).

At this point, your description seems a bit vague in terms of what is
working and what is not.  If you do the additional testing to narrow
down specifically the failure case you are experiencing, I will see
what I can do.

That said, I'm preparing a tree with Robert's patch since I am pretty
confident at least his particular problem is now addressed.

Thanks,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bisected regression in tuner-xc2028 on DVICO dual digital 4

2009-11-05 Thread Devin Heitmueller

On Thu, Nov 5, 2009 at 3:57 PM, Vincent McIntyre
vincent.mcint...@gmail.com wrote:
 I have one of these too.

 lsusb:
 Bus 003 Device 003: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
 (ZL10353+xc2028/xc3028) (initialized)
 Bus 003 Device 002: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
 (ZL10353+xc2028/xc3028) (initialized)

 In addition I have a DViCO Dual Digital Express which is a PCIe card
 based on Conexant, with the Zarlink frontend.
 lspci:
 04:00.0 Multimedia video controller [0400]: Conexant Systems, Inc.
 CX23885 PCI Video and Audio Decoder [14f1:8852] (rev 02)
        Subsystem: DViCO Corporation Device [18ac:db78]
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
 Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
 TAbort- MAbort- SERR- PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 19
        Region 0: Memory at 9000 (64-bit, non-prefetchable) [size=2M]
        Capabilities: access denied
        Kernel driver in use: cx23885
        Kernel modules: cx23885

Crap.  This is the price I pay for not having noticed Robert included
a launchpad ticket with the dmesg output.

Yeah, it's a zl10353, so I know what the problem is.  Let me look at
the code and send you a patch for testing.  If you don't hear back
from me within 24 hours, ping me again.

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bisected regression in tuner-xc2028 on DVICO dual digital 4

2009-11-05 Thread Devin Heitmueller

On Thu, Nov 5, 2009 at 6:45 PM, Robert Lowery rglow...@exemail.com.au wrote:
 Do you mean something like this (untested) patch?  I'll try it out tonight.

 diff -r 43878f8dbfb0 linux/drivers/media/dvb/dvb-usb/cxusb.c
 --- a/linux/drivers/media/dvb/dvb-usb/cxusb.c   Sun Nov 01 07:17:46 2009
 -0200
 +++ b/linux/drivers/media/dvb/dvb-usb/cxusb.c   Fri Nov 06 10:39:38 2009
 +1100
 @@ -666,6 +666,14 @@
        .parallel_ts = 1,
  };

 +static struct zl10353_config cxusb_zl10353_xc3028_config_no_i2c_gate = {
 +       .demod_address = 0x0f,
 +       .if2 = 45600,
 +       .no_tuner = 1,
 +       .parallel_ts = 1,
 +       .disable_i2c_gate_ctrl = 1,
 +};
 +
  static struct mt352_config cxusb_mt352_xc3028_config = {
        .demod_address = 0x0f,
        .if2 = 4560,
 @@ -897,7 +905,7 @@
        cxusb_bluebird_gpio_pulse(adap-dev, 0x02, 1);

        if ((adap-fe = dvb_attach(zl10353_attach,
 -                                  cxusb_zl10353_xc3028_config,
 +                                  cxusb_zl10353_xc3028_config_no_i2c_gate,
                                   adap-dev-i2c_adap)) == NULL)
                return -EIO;

Wow, that looks shockingly similar to the patch I did for an em28xx
boards a couple of months ago, even down to the part where you added
_no_i2c_gate to the end!  :-)

Yeah, that's the fix, although from the diff I can't tell if you're
doing it for all zl10353 boards in cxusb.c or just yours.  I would
have to see the source to know for sure.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bisected regression in tuner-xc2028 on DVICO dual digital 4

2009-11-05 Thread Devin Heitmueller

On Thu, Nov 5, 2009 at 9:31 PM, Robert Lowery rglow...@exemail.com.au wrote:
 Devin,

 I have confirmed the patch below fixes my issue.  Could you please merge
 it for me?

 Thanks

 -Rob

Sure.  I'm putting together a patch series for this weekend with a few
different misc fixes.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-dvb] KWORLD 323U, kernel panic when trying to access ALSA interface

2009-11-04 Thread Devin Heitmueller

2009/11/4 Marios Andreopoulos opensou...@andmarios.com:
 Just a small update.

 After this message of yours: 
 http://www.linuxtv.org/pipermail/linux-dvb/2009-October/032442.html
 I tried again the v4l-dvb tree and now my card works without problems!

 I don’t know what the problem was with your tree. I think another tree I had 
 used previously copied it’s modules to a non standard location in 
 /lib/modules/current-kernel/ and thus its modules took precedence over the 
 kernels’, yours’ or v4l-dvb’s modules.

 It just happened that I upgraded my kernel recently and found out that 
 v4l-dvb works now.

 Thanks!

Well the fix I mentioned for the audio panic was merged on October
29th (and that's the only change that's been made to the driver in
five months).  This makes me think that perhaps you made some mistake
when you tried out the testing tree I sent you.

Regardless, it's a relief to hear that it's working for you now, since
I didn't have any idea what the problem could be if it wasn't the
crash that I fixed.

I'll see about getting this backported to stable, since 2.6.31 users
are likely to hit this issue as they upgrade to newer distros (such as
the recently released Ubuntu 9.10).

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 1164:1f08 YUAN High-Tech STK7700PH kernel crash in Ubuntu 9.10

2009-11-02 Thread Devin Heitmueller

On Mon, Nov 2, 2009 at 8:28 AM, Patrick Byrne pjlby...@gmail.com wrote:
 Hi,

 I have an Aopen MP45-DR mini-pc. I am trying to get a DVB-T card
 working in it. The DVB card is a Mini-PCI express card. It fits on a
 minicard slot inside the pc.

 I can activate the 'Firmware for DVB cards' in the Hardware Drivers applet:
snip

This was fixed quite some time ago in the v4l-dvb trunk and the Ubuntu
maintainers just haven't backported the fix into their tree.  It's
being tracked here:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/429662

So you can install the latest v4l-dvb tree via the instructions at
http://linuxtv.org/repo or you can complain to your distribution
maintainers to backport the fix.

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-dvb] somebody messed something on xc2028 code?

2009-10-31 Thread Devin Heitmueller

On Sat, Oct 31, 2009 at 8:35 AM, Albert Comerma
albert.come...@gmail.com wrote:
 Hi all, I just updated my ubuntu to karmic and found with surprise that with
 2.6.31 kernel my device does not work... It seems to be related to the
 xc2028 code part since the kernel explosion happens when you try to tune the
 device, here it's my dmesg, any idea?

 Albert

 [ 1622.032196] usb 1-1: new high speed USB device using ehci_hcd and address
 4
 [ 1622.166041] usb 1-1: configuration #1 chosen from 1 choice
 [ 1622.167341] dvb-usb: found a 'Pinnacle Expresscard 320cx' in cold state,
 will try to load a firmware
 [ 1622.167353] usb 1-1: firmware: requesting dvb-usb-dib0700-1.20.fw
 [ 1622.188465] dvb-usb: downloading firmware from file
 'dvb-usb-dib0700-1.20.fw'
 [ 1622.396737] dib0700: firmware started successfully.
 [ 1622.900198] dvb-usb: found a 'Pinnacle Expresscard 320cx' in warm state.
 [ 1622.900308] dvb-usb: will pass the complete MPEG2 transport stream to the
 software demuxer.
 [ 1622.900759] DVB: registering new adapter (Pinnacle Expresscard 320cx)
 [ 1623.157839] DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)...
 [ 1623.158165] xc2028 4-0061: creating new instance
 [ 1623.158173] xc2028 4-0061: type set to XCeive xc2028/xc3028 tuner
 [ 1623.158333] input: IR-receiver inside an USB DVB receiver as
 /devices/pci:00/:00:1a.7/usb1/1-1/input/input16
 [ 1623.158418] dvb-usb: schedule remote query interval to 50 msecs.
 [ 1623.158427] dvb-usb: Pinnacle Expresscard 320cx successfully initialized
 and connected.
 [ 1670.979678] CE: hpet increasing min_delta_ns to 15000 nsec
 [ 1753.316527] BUG: unable to handle kernel NULL pointer dereference at
 0008
 [ 1753.316543] IP: [c03a8a13] _request_firmware+0x1f3/0x250
 [ 1753.316562] *pde = 
 [ 1753.316570] Oops:  [#2] SMP
 [ 1753.316578] last sysfs file:
 /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0/charge_full
 [ 1753.316586] Modules linked in: tuner_xc2028 dvb_usb_dib0700 dib7000p
 dib7000m dvb_usb dvb_core dib3000mc dibx000_common dib0070 hidp binfmt_misc
 vboxnetflt vboxnetadp vboxdrv ppdev parport_pc snd_hda_codec_idt
 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm arc4
 ecb snd_seq_dummy snd_seq_oss iwlagn bridge stp bnep snd_seq_midi iwlcore
 snd_rawmidi joydev iptable_nat snd_seq_midi_event mac80211 nf_nat snd_seq
 nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 snd_timer snd_seq_device
 iptable_mangle snd sbp2 dell_wmi psmouse iptable_filter serio_raw ip_tables
 soundcore x_tables snd_page_alloc cfg80211 uvcvideo videodev v4l1_compat
 sdhci_pci sdhci led_class lp btusb dell_laptop dcdbas nvidia(P) parport
 usbhid dm_raid45 xor ohci1394 video output ieee1394 tg3 intel_agp agpgart
 [ 1753.316753]

This was actually a regression related to the dib7000 driver and any
tuner that uses request_firmware().  I checked in a fix for one board
that hit it.  It was introduced because 2.6.28 started using the first
parameter passed to request_firmware(), and the dib7000 driver was
sending null.

Can you clarify which bridge your device uses.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-dvb] somebody messed something on xc2028 code?

2009-10-31 Thread Devin Heitmueller

On Sat, Oct 31, 2009 at 8:35 AM, Albert Comerma
albert.come...@gmail.com wrote:
 Hi all, I just updated my ubuntu to karmic and found with surprise that with
 2.6.31 kernel my device does not work... It seems to be related to the
 xc2028 code part since the kernel explosion happens when you try to tune the
 device, here it's my dmesg, any idea?

 Albert

Oh, you're using the stock 2.6.31 which didn't get my fix yet.  Please
try the latest v4l-dvb tree and see if it still happens.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cx18: YUV frame alignment improvements

2009-10-31 Thread Devin Heitmueller

On Sat, Oct 31, 2009 at 4:16 PM, Andy Walls awa...@radix.net wrote:
All,

http://linuxtv.org/hg/~awalls/cx18-yuv

I have checked in some improvements to YUV handling in the cx18
driver.

There was a problem in that a lost/dropped buffer between the cx18
driver and the CX23418 firmware would cause the video frame alignment to
be lost with no easy way to recover.

These changes do the following:

1. Force YUV buffer sizes to be large enough to hold either 1 full 525
line system frame or 1 full 625 line system frame with new module
options and defaults. That makes the YUV buffers quite large, but
allows for 1 frame per buffer for full sized video frames.

2. Not being able to allocate the now large YUV buffers is non-fatal.
The driver will still load and work for other stream types, even if it
can't get the YUV buffers. A warning is blurted out in the log, in case
YUV buffers can't be allocated.

3. __GFP_REPEAT has been added when trying to make the initial video
buffer allocations. After I added this, I never had the large YUV
buffers fail to be allocated.

4. We now lie to the firmware about the actual YUV buffer size, so that
the firmware always thinks the buffers are exactly large enough to hold
exactly an integral number of YUV frames based on the image height.
This means that dropped/lost YUV buffers between the cx18 driver and the
CX23418 firmware will only drop whole frames and no misalignment should
occur.

# modinfo cx18
[...]
parm: enc_yuv_buffers:Encoder YUV buffer memory (MB). (enc_yuv_bufs
can override)
Default: 3 (int)
parm: enc_yuv_bufsize:Size of an encoder YUV buffer (kB)
Allowed values:
0 (do not allocate YUV buffers)
507 (when never capturing 625 line systems)
608 (when capturing 625 and/or 525 line
systems)
Default: 608 (int)
parm: enc_yuv_bufs:Number of encoder YUV buffers
Default is computed from other enc_yuv_* parameters
(int)
[...]

# modprobe cx18
# mplayer /dev/video32 -demuxer rawvideo -rawvideo
w=720:h=480:format=hm12:ntsc

You can add 'debug=264' to the modprobe line to watch the size of the
payloads coming back from the firmware to make sure they are an integral
number of frames, but logging stats on every noticably degrades
performance.

Regards,
Andy

Hi Andy,

How does this code work if the cx23418 scaler is used (resulting in
the size of the frames to be non-constant)? Or is the scaler not
currently supported in the driver?

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [linux-dvb] Possible error in firedtv-1394.o?

2009-10-30 Thread Devin Heitmueller

On Fri, Oct 30, 2009 at 3:48 PM, Andreas Breitbach
andreas.breitb...@gmail.com wrote:
 Hello all.

 I subscribed to this mailing list to report a possible error in the
 above mentioned module. For your better understanding, some details
 about my situation: I upgraded yesterday from Jaunty(Ubuntu) to the new
 Karmic. I had a 0ccd:0069 TerraTec Electronic GmbH Cinergy T XE DVB-T
 Receiver(lsusb output), which worked with the drivers avaible from
 http://linuxtv.org/hg/~anttip/. After the upgrade, I tried to compile
 and install the modules necessary for the stick by entering make all.
 It compiles til reaching firedtv-1394.o, I attached the output, which
 complains about this specific module.
 As I'm not a programmer, but rather a normal user who clued together how
 to get this stick working once, I fear I can not be of much help in
 debugging. Nonetheless, I'd be very interested in knowing about the
 status of this and when my TV will be back working(or how I could
 circumvent this error).

Hi Andy,

Yeah, this is a known issue with the build process under Karmic.  The
iee1394 is enabled by default but Karmic's packaging of the kernel
headers is missing some files that are needed by the firedtv driver.

To workaround the issue, I usually just open v4l/.config and change
the firedtv driver from =m to =n.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: HVR-950Q problem under MythTV

2009-10-29 Thread Devin Heitmueller

On Thu, Oct 29, 2009 at 1:33 AM, Bob Cunningham rcunn...@acm.org wrote:
 I spoke too soon: Switching between SD and HD channels (or vice-versa)
 always works the first time, but generally dies the next time I try.  The
 behavior is very inconsistent:  If I switch from SD to HD 720p or higher,
 the tuner goes away the next time I try to tune an SD channel.  If I switch
 between SD and 480i HD channels, I can do so up to 4 times before it stops
 working.

 I can switch among SD channels with no problem, and I can switch between HD
 channels of any resolution with no problem.  Only switching back and forth
 between HD and SD causes the problem, and it always happens, sooner or
 later.

 Is there a way to force a quick  dirty device reinitialization?  Right
 now, I'm killing mythfrontend and mythbackend, re-plugging the HVR-950Q, and
 restarting mythbackend and mythfrontend.  Probably overkill.  Is there an
 easier way?

In this context, we are not talking about SD versus HD - we're talking
about analog versus digital.  You should have no trouble switching
between SD ATSC channels and HD ATSC channels (since the hardware
literally cannot tell the difference).  However, it's not *too*
surprising to find issues going back and forth between analog and
digital.

Are you sure you put both the analog and digtial video sources into
the same recording group?  If not, it's possible that MythTV will
attempt to use both the analog and digtial parts of the card at the
same time, which is not permitted by the hardware.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Call for Testers: HVR-1600 Improvements

2009-10-29 Thread Devin Heitmueller

Hello all,

If you are an HVR-1600 user who has noticed the ClearQAM tuning
performance under Linux was worse than under Windows, the following
should make you happy.

There is now a tree that contains various fixes for ClearQAM tuning.
These have been measured to put the SNR performance on-par with the
Windows driver.

http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-perf-2

The goal is to submit this upstream, but before that we want to get
some people to try it out first and submit feedback on their
experience.

Thanks go out to ONELAN Limited for sponsoring this work!

Feedback (good or bad) on the KernelLabs blog or the linux-media
mailing list would be appreciated.

Thanks,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: HVR-950Q problem under MythTV

2009-10-28 Thread Devin Heitmueller

On Wed, Oct 28, 2009 at 10:10 PM, Bob Cunningham rcunn...@acm.org wrote:
 I just completed a fresh install of MythTV 0.22 RC1 on my fully-updated
 Fedora 11 system.  My tuner is an HVR-950Q, connected to cable.  The tuner
 works fine under tvtime (SD) and xine (HD).

 All MythTV functions work, except LiveTV.  The problem is that mythfrontend
 times out waiting for the HVR-950Q to tune to the first station.  This
 appears to be due to the very long HVR-950Q firmware load time, since no
 errors are reported by the backend.

 Unfortunately, mythfrontend has a hard-wired 7 second timeout for most
 requests sent to the backend.  It seems this timeout works fine under normal
 circumstances for every other tuner MythTV works with.

 The following is repeated in dmesg after every attempt:

  xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)...
  usb 1-2: firmware: requesting dvb-fe-xc5000-1.6.114.fw
  xc5000: firmware read 12401 bytes.
  xc5000: firmware uploading...
  xc5000: firmware upload complete...

 It looks like the HVR-950Q driver reloads the firmware at every possible
 opportunity, independent of the hardware state, each time either the SD or
 HD device is opened, such as when changing from an SD channel on /dev/video0
 to an HD channel on /dev/dvb/adapter0.  Is this necessary?

 Is it possible to tell the driver to ease up on the firmware reloads?  I
 don't mind if the first attempt fails, but the second attempt should succeed
 (without a reload).

 Alternatively, are faster firmware loads possible?

 Should I open a bug on this?

Hello Bob,

In order to avoid the firmware reloading condition, you need to add a
modprobe option called no_poweroff=1 for the xc5000 driver to your
modprobe.conf file and then reboot your computer.  I agree that this
is a very annoying workaround, but have not had a chance to try to
find another solution (the i2c master in the au0828 hardware is poorly
designed and this same problem occurs in Windows but the problem is
not as noticeable because the Windows application doesn't as
aggressively power down the tuner).

Also, in order for the video to be rendered properly, you need to make
sure your capture resolution for LiveTV mode and the various capture
modes is set to 720x480 (the default in MythTV is 480x480).  Without
this change, the picture will appear to be vertically stretched.  This
is actually a bug in MythTV not properly handling analog capture
products that do not have an onboard hardware scaler (I did work in
0.22 to get the analog support working but have not had an opportunity
to fix this bug yet).

If you still have trouble, feel free to reply to this message.

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: HVR-950Q problem under MythTV

2009-10-28 Thread Devin Heitmueller

On Thu, Oct 29, 2009 at 12:47 AM, Bob Cunningham rcunn...@acm.org wrote:
 For F11, I appended the line options xc5000 no_poweroff=1 to
 /etc/modprobe.d/local.conf

 Rather than power down (shudder), I did the following:
 1. Unplug HVR-950Q
 2. rmmod xc5000
 3. modprobe xc5000 no_poweroff=1
 4. Plug in HVR-950Q

You would be shocked how many people have trouble with those four
steps.  So now I just tell people to reboot.

 All is well with the world: The tuner is tuning, MythTV is mythic, and I am
 a vidiot.

That's great.  Bear in mind that I only did a minimal amount of
burn-in under MythTV, so if you see other issues, please speak up.  I
basically did enough to get rid of the segfaults, show the user video,
and cleanup a couple of errors in the mythbackend.log (by implementing
the hue and saturation controls).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFCv2: Media controller proposal

2009-10-27 Thread Devin Heitmueller

On Tue, Oct 27, 2009 at 4:04 AM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
 Hi

 (repeating my preamble from a previous post)

 This is a general comment to the whole media controller work: having
 given a talk at the ELC-E in Grenoble on soc-camera, I mentioned briefly a
 few related RFCs, including this one. I've got a couple of comments back,
 including the following ones (which is to say, opinions are not mine and
 may or may not be relevant, I'm just fulfilling my promise to pass them
 on;)):

 1) what about DVB? Wouldn't they also benefit from such an API? I wasn't
 able to reply to the question, whether the DVB folks know about this and
 have a chance to take part in the discussion and eventually use this API?

The extent to which DVB applies is that the DVB devices will appear in
the MC enumeration.  This will allow userland to be able to see
hybrid devices where both DVB and analog are tied to the same tuner
and cannot be used at the same time.

 2) what I am even less sure about is, whether ALSA / ASoC have been
 mentioned as possible users of MC, or, at least, possible sources for
 ideas. ASoC has definitely been mentioned as an audio analog of
 soc-camera, so, I'll be looking at that - at least at their documentation
 - to see if I can borrow some of their ideas:-)

ALSA devices will definitely be available, although at this point I
have no reason to believe this will require changes the ALSA code
itself.  All of the changes involve enumeration within v4l to find the
correct ALSA device associated with the tuner and report the correct
card number.  The ALSA case is actually my foremost concern with
regards to the MC API, since it will solve the problem related to
applications such as tvtime figuring out which ALSA device to playback
audio on.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx DVB modeswitching change: call for testers

2009-10-26 Thread Devin Heitmueller

On Mon, Oct 26, 2009 at 12:02 PM, Antti Palosaari cr...@iki.fi wrote:
 Is there any way to speed up Empia to handle streams bigger than ~45
 Mbit/sec?

Can you add a debug line that dumps out the values of register 0x01
and register 0x5d and then send me the values?

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Pinnacle PCTV DVB-T support.

2009-10-23 Thread Devin Heitmueller

On Fri, Oct 23, 2009 at 10:12 AM,  m...@spanberg.se wrote:
 Hi!

 I found my old Pinnacle PCTV DVB-T card and thought I might put it to use.
 Since I have used it on linux before (about two years ago) with the em28xx
 driver I didn't think it would be any problems.

 However I can't seem to get it to work.
snip

Yes, that particular board is known to not work.  I never got around
to adding the support for the mainline driver.  I started to work on
it with a user earlier in the year, but I couldn't get it to work
immediately and since I didn't have the hardware I couldn't really
debug it further without a level of effort that wasn't worth my time.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pinnacle pctv 7010ix and saa716x

2009-10-23 Thread Devin Heitmueller

On Fri, Oct 23, 2009 at 11:45 AM, Benjamin Valentin
benpi...@zedat.fu-berlin.de wrote:
 Hello,
 I have a Pinnacle pctv 7010ix that is oddly recognized as a Pinnacle
 PCTV 3010iX [1].
 I found that the SAA7162 chip used in that device is supported while
 the device itself is not. I was a bit confused wich of the various
 repositories I encountered reflects the latest version of development,
 however, none of the linux/drivers/media/video/saa7164/saa7164-cards.c
 contained a string referring to said pinnacle card.
 It seems like the only obstacle that keeps the card from working is the
 missing configuration for the board - how does one figure out that?
 I would like to get some hints on how to determine necessary
 configuration or test some.

You cannot use a saa7162 based device with the saa7164 driver.  They
chipsets are too dissimilar.

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Details about DVB frontend API

2009-10-22 Thread Devin Heitmueller

On Thu, Oct 22, 2009 at 3:13 PM, Jean Delvare kh...@linux-fr.org wrote:
 Hi folks,

 I am looking for details regarding the DVB frontend API. I've read
 linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER,
 FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS
 commands return, however it does not give any information about how the
 returned values should be interpreted (or, seen from the other end, how
 the frontend kernel drivers should encode these values.) If there
 documentation available that would explain this?

 For example, the signal strength. All I know so far is that this is a
 16-bit value. But then what? Do greater values represent stronger
 signal or weaker signal? Are 0x and 0x special values? Is the
 returned value meaningful even when FE_HAS_SIGNAL is 0? When
 FE_HAS_LOCK is 0? Is the scale linear, or do some values have
 well-defined meanings, or is it arbitrary and each driver can have its
 own scale? What are the typical use cases by user-space application for
 this value?

 That's the kind of details I'd like to know, not only for the signal
 strength, but also for the SNR, BER and UB. Without this information,
 it seems a little difficult to have consistent frontend drivers.

 Thanks,
 --
 Jean Delvare

Hi Jean,

I try to raise this every six months or so.  Check the mailing list
archive for SNR in the subject line.

Yes, it's all screwed up and inconsistent across demods.  I took a
crack at fixing it a few months ago by proposing a standard (and even
offering to fix up all the demods to be consistent), and those efforts
were derailed by some individuals who wanted what I would consider a
perfect interface at the cost of something that worked for 98% of
the userbase (I'm not going to point any fingers).  And what did we
get as a result?  Nothing.

I could have had this problem solved six months ago for 98% of the
community, and instead we are right where we have been since the
beginning of the project.

/me stops thinking about this and goes and gets some coffee

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kworld 315U help?

2009-10-21 Thread Devin Heitmueller

On Thu, Oct 22, 2009 at 12:03 AM, Franklin Meng fmeng2...@yahoo.com wrote:
 Here are some more stuff in the trace that was not decoded by the 
 parse_em28xx script..

 So what we know from this list of unknowns...

 0xa0 is the eeprom
 0x4a is the SAA
 0x42 ??.
 0xd0 ??
 0x20 ??
 0xc6 ??
 0xc4 ??
 0xc2 Thomson tuner.

c4 and c6 are probably also the tuner.  I know that K-World makes some
products with the same name but different regions.  Is your version of
the 315U an ATSC hybrid tuner?  If so, then one of those addresses is
probably the demod.

Also, the trace you sent is just an excerpt, but it's possible that
the driver is probing for devices and the requests are failing because
the hardware isn't present (the Windows driver supports a variety of
different hardware combinations).  Usually you can tell by looking for
a read from register 0x05 immediately after the i2c read.  If register
0x05 is nonzero, then the i2c read operation failed.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pctv nanoStick Solo not recognized

2009-10-19 Thread Devin Heitmueller

On Sun, Oct 18, 2009 at 5:41 PM, Matteo Miraz telegraph.r...@gmail.com wrote:
 Hi,

 I've just bought a new DVB USB card, but it seems that the current
 version of linux tv does not recognize it at all.
 I tried both the ubuntu kernel (9.04 and 9.10) and the latest drivers
 downloaded with mercurial from http://linuxtv.org/hg/v4l-dvb

 The card is a PCTV nanoStick Solo, and chip seems to be a 73E SE.
 Looking at the lsusb output (reported below), it seems that it is not
 a pinnacle, but a new brand (the Vendor ID is different from the
 pinnacle's one).

 Can you help me?

 Thanks,
 Matteo

As far as I can see, support for the PCTV 73E-SE (usb id 2013:0245)
was introduced in hg rev 12886 on September 2nd.  This would have been
too late to make it for the Karmic release.

You can get the device working in your environment by installing the
latest v4l-dvb tree.  You can find directions here:

http://linuxtv.org/repo

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pctv nanoStick Solo not recognized

2009-10-19 Thread Devin Heitmueller

On Mon, Oct 19, 2009 at 4:28 PM, Matteo Miraz telegraph.r...@gmail.com wrote:
 in the changeset 12886:ba22a9decfab was added a device called
 USB_PID_PINNACLE_PCTV73ESE, with id 0245

 However, the vendor is USB_VID_PINNACLE ( 0x2304 ) instead of 0x2013 (
 as reported for my usb dvb by lsusb )

 How can I fix it? How can I create a new vendor with the correct ID,
 and try if the module works? I'm new to the kernel development, so I'm
 afraid to make mistakes!

I've sent some email to the engineer I know over at PCTV Systems, and
will report back when I know more.  My suspicion is that they changed
the USB ID and we just need to update the driver to allow for either
USB ID to be associated with the device.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pctv nanoStick Solo not recognized

2009-10-19 Thread Devin Heitmueller

On Mon, Oct 19, 2009 at 5:51 PM, Matteo Miraz telegraph.r...@gmail.com wrote:
 Devin,

 thanks for the support.

 In the meanwhile, can I try to force the new vendor id?
 Since I have another pinnacle USB device, I was thinking about
 creating a new vendor (something like USB_VID_PINNACLE2).
 Is it enough to add it just after the USB_VID_PINNACLE definition and
 change the 57th line to

 { USB_DEVICE(USB_VID_PINNACLE2, USB_PID_PINNACLE_PCTV73ESE) },

 or should I do something else?

You can definitely give that a try and see if it starts working.  I
would suggest you call it USB_VID_PCTVSYSTEMS though, since that is
the new name.  If it works, send in a patch and we'll merge it.

My speculation is that they got a new USB ID because of the Hauppauge
acquisition, and they started shipping the existing products with the
new ID (thereby we would need both USB ids in the driver).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New member, trying to setup a Pinnacle Quatro stick

2009-10-16 Thread Devin Heitmueller

On Fri, Oct 16, 2009 at 5:45 PM, ps1 p...@schirrms.net wrote:
 Hi,

 I recenly own a Pinnacle (or Pctv now) Quatro Stick (also known as  510e)
 The product is a small USB stick, able to receive Analog TV, DVB-T TV,
 Analog Radio and also DVB-C TV (That is, cable TV).

 The product is running under windows (even if I'm not so impressed by the
 analog TV reception, but this is another story).

 Under Linux (I'm using a Mandriva 2009 spring distro, with a 2.6.29-6
 kernel), the system says nothing about the stick.

 More exactly : the stick is recognized via lsusb, but nothing happend whem I
 plug the device (I don't know if the system should ask for a firmware file,
 but there is no new device in /dev after plugging the device).

 I just compile the current version of v4l-dvb, as explained on the Wiki,
 (had some trouble to remove the kernel's drivers witch are gziped), but a
 grep in em28xx-card.c let me think that my device is not supported. The VID
 PID are 2304:0242

 I think that the EMPIA chipset is an em2885 chip, and I didn't find any
 information about this chip, too.

 Here are the other informations that I was able to gatter :
 When I plug the device, I got theses messages in /usr/adm/messages :
 -
 Oct 16 23:27:31 p4c2400 klogd: usb 5-6: new high speed USB device using
 ehci_hcd and address 75
 Oct 16 23:27:31 p4c2400 klogd: usb 5-6: New USB device found, idVendor=2304,
 idProduct=0242
 Oct 16 23:27:31 p4c2400 klogd: usb 5-6: New USB device strings: Mfr=1,
 Product=2, SerialNumber=3
 Oct 16 23:27:31 p4c2400 klogd: usb 5-6: Product: PCTV 510e
 Oct 16 23:27:31 p4c2400 klogd: usb 5-6: Manufacturer: Pinnacle Systems
 Oct 16 23:27:31 p4c2400 klogd: usb 5-6: SerialNumber: 123456789012
 Oct 16 23:27:31 p4c2400 klogd: usb 5-6: configuration #1 chosen from 1
 choice
 Oct 16 23:27:31 p4c2400 pulseaudio[2723]: alsa-sink.c: ALSA woke us up to
 write new data to the device, but there was actually nothing to write!
 Oct 16 23:27:31 p4c2400 pulseaudio[2723]: alsa-sink.c: Most likely this is a
 bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA
 developers.
 Oct 16 23:27:31 p4c2400 pulseaudio[2723]: alsa-sink.c: We were woken up with
 POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another
 value  min_avail.
 

 i can manually load em28xx, but there's no device creation at this moment.

 Any ideas ? Any more tests I can do ?

 Thanks,
 Pascal

Hello Pascal,

The em2885 isn't the problem - all of the devices I have seen that
have the em2885 also have the drx-k demodulator chip, which is
completely unsupported.

If you want to open it up and find out what other chips it contains,
we can see if it can be supported.  If it uses the Micronas drx-k,
then you are out of luck.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-dvb] KWORLD 323U, kernel panic when trying to access ALSA interface

2009-10-15 Thread Devin Heitmueller

2009/9/28 Marios Andreopoulos opensou...@andmarios.com:
 On Monday 28 of September 2009, Devin Heitmueller wrote:

 Hello Marios,

 I started doing some debugging em28xx audio on the HVR-950 and hit
 what is probably the same panic (which occurs as soon as you run the
 arecord command).  I've got a stack dump and am actively debugging the
 issue.

 It seems that a regression has been recently introduced.

 Devin



 If there is any way I can help please let me know.
 I do not know much about developing or debugging software but I believe I'm 
 able to follow instructions to get a dump or do some trials if there is a 
 need.

 Thanks for the really quick reply,
 Marios

Hello Marios,

Sorry about the extended delay on this.  Please try out the following
tree and see if you still hit a panic:

http://www.kernellabs.com/hg/~dheitmueller/em28xx-audio-panic

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx DVB modeswitching change: call for testers

On Wed, Oct 14, 2009 at 6:25 AM, Giuseppe Borzi gbo...@gmail.com wrote:
 Hello all,

 I have setup a tree that removes the mode switching code when
 starting/stopping streaming.  If you have one of the em28xx dvb
 devices mentioned in the previous thread and volunteered to test,
 please try out the following tree:

 http://kernellabs.com/hg/~dheitmueller/em28xx-modeswitch

 In particular, this should work for those of you who reported problems
 with zl10353 based devices like the Pinnacle 320e (or Dazzle) and were
 using that one line change I sent this week.  It should also work with
 Antti's Reddo board without needing his patch to move the demod reset
 into the tuner_gpio.

 This also brings us one more step forward to setting up the locking
 properly so that applications cannot simultaneously open the analog
 and dvb side of the device.

 Thanks for your help,

 Devin

 Hello Devin,
 I've just downloaded, compiled and installed em28xx-modeswitch.
 Unfortunately, it doesn't work and doesn't even
 create /dev/dvb, /dev/videoX, /dev/vbiX. Only /dev/dsp1 is created.
 The dmesg is attached to this email. As you can see it ends up in
 errors.
 One last note, I downloaded from the bz2 link.

 Cheers.

Did you run make unload before you plugged in the device?

Do me a favor - unplug the device, reboot the PC, plug it back in and
see if it still happens.  I just want to be sure this isn't some sort
of issue with conflict between the new and old modules before I debug
this any further.

Thanks,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Poor reception with Hauppauge HVR-1600 on a ClearQAM cable feed

On Wed, Oct 14, 2009 at 7:01 AM, Simon Farnsworth
simon.farnswo...@onelan.com wrote:
 Andy Walls wrote:
 Have your remote user read

 http://www.ivtvdriver.org/index.php/Howto:Improve_signal_quality

 and take any actions that seem appropriate/easy.

 I'll try that again - they're grouching, because their TV is fine, and
 the same card in a Windows PC is also fine. It's just under Linux that
 they're seeing problems, so I may not be able to get them to co-operate.

 The in kernel mxl5005s driver is known to have about 3 dB worse
 performance for QAM vs 8-VSB (Steven Toth took some measurements once).

 Am I misunderstanding dmesg here? I see references to a Samsung S5H1409,
 not to an mxl5005s; if I've read the driver code correctly, I'd see a
 KERN_INFO printk for the mxl5005s when it comes up.

Simon, the HVR-1600 has both an s5h1409 and an mxl5005s - the s5h1409
is the digital demodulator and the mxl5005s is the tuner chip.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx DVB modeswitching change: call for testers

On Wed, Oct 14, 2009 at 10:06 AM, Giuseppe Borzi gbo...@gmail.com wrote:
 Hello Devin,
 I did as you suggested. Unplugged the stick reboot and plug it again.
 And just to be sure I did it two times. Now the device works, but it is
 unable to change channel. That is to say, when I use the command vlc
 channels.conf it tunes to the first station in the channel file and
 can't change it. Other apps (xine, kaffeine) that seems to change to
 the latest channel don't work at all. The dmesg output after plugging
 the driver is in attach. In dmesg I noticed lines like this

 [drm] TV-14: set mode NTSC 480i 0

 I suppose this hasn't anything to do with the analog audio problem, but
 just to be sure I ask you. Also, using arecord/aplay for analog audio I
 get an underrun error message

 arecord -D hw:1,0 -r 32000 -c 2 -f S16_LE | aplay -
 Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 32000 Hz,
 Stereo Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 32000
 Hz, Stereo underrun!!! (at least -1255527098942.108 ms long)

 Cheers.

Ok, let me look at the code and see what I can figure out.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx DVB modeswitching change: call for testers

On Wed, Oct 14, 2009 at 10:30 AM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
 Devin,

 You can't simply remove the DVB gpio setup there. It is used when you change
 from analog/digital, when you restore from hibernation and to turn on the 
 demod
 on hybrid devices, and to turn it off after stopping DVB. If you're having 
 troubles
 there, then probably the DVB demod poweron/reset gpio sequence is wrong or
 incomplete.

The em28xx_dvb_bus_ctrl() callback should already be putting it into
digital mode when the frontend gets opened.  The point behind the
change is that we should not be switching in and out of dvb mode
whenever somebody starts/stops streaming.  It should be controlled
based on opening closing the frontend (which is what the ts_bus_ctrl
callback should accomplish).

We ran into the issue because the dvb gpio for the board in question
actually strobes the reset rather than just taking it out of reset.
While I could change the dvb_gpio to match some of the other boards,
we really *should* be strobing the reset after powering up the chip.

If we're really relying on the calls in the start_feed() callback when
coming out of hibernation, then the code is broken in that case as
well, since there is no guarantee the demod is properly
re-initialized.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Poor reception with Hauppauge HVR-1600 on a ClearQAM cable feed

On Wed, Oct 14, 2009 at 11:12 PM, Andy Walls awa...@radix.net wrote:
 On Wed, 2009-10-14 at 12:01 +0100, Simon Farnsworth wrote:
 Andy Walls wrote:
  Have your remote user read
 
  http://www.ivtvdriver.org/index.php/Howto:Improve_signal_quality
 
  and take any actions that seem appropriate/easy.
 
 I'll try that again - they're grouching, because their TV is fine, and
 the same card in a Windows PC is also fine. It's just under Linux that
 they're seeing problems, so I may not be able to get them to co-operate.


 Right, the windows driver code for the mxl5005s is better.  Inform him
 that the linux driver for the mxl5005s could be better.  If he has any
 contacts at MaxLinear to get the datasheet and programming manual
 released to me, I can make the linux driver better.

I've got the datasheet.  It's just one of those projects on my list
where I have to get around to hooking up the i2c analyzer to a running
board, capture the block that gets programmed into the chip under
Windows, and compare the bits against Linux.

I've just been tied up in too much other stuff to do the legwork required.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PULL] http://kernellabs.com/hg/~dheitmueller/em28xx-audio-panic

Hello Mauro,

Please pull from
http://kernellabs.com/hg/~dheitmueller/em28xx-audio-panic for the
following:

em28xx: fix panic that can occur when starting audio streaming

Since this is a rather nasty kernel panic, we should probably look at
getting this back into stable as well.

Thanks,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx mode switching

On Tue, Oct 13, 2009 at 2:27 PM,  xwang1...@email.it wrote:
 Hi Devin,
 let me know if you need a tester for the EMPIRE_DUAL_TV.
 In case I will install the latest v4l driver on my old notebook which has a
 clean kubuntu 9.04 distro. On the newer notebook I'm using my new Dikom
 DK-300 device which does not work with the latest v4l drivers and which I
 can use using a patched version of the main v4l driver (thanks to Dainius
 Ridzevicius). If you have some spare time for this device too...
 Xwang

Hi xwang,

Well, I'm hoping to setup a tree sometime this week (and test it with
my devices).  Assuming it works, I will put out a call for testers
such as yourself.

Regarding your DK-300, if you send the diff between the main v4l
driver and the patched version, we can take a look at what would be
required to merge it upstream.

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dazzle TV Hybrid USB and em28xx

On Tue, Oct 13, 2009 at 3:31 PM, Giuseppe Borzi gbo...@gmail.com wrote:
 Thanks Devin,
 now DVB works as expected, i.e. I can change channel and w_scan
 finds the channels available in my area. The stick is recognized as
 card=1 instead of 53 as I expected, but still it works fine.
 Still no sound for analog TV, but that's a minor problem.

 Thanks again.

Can you please provide the output of dmesg after connecting the card?
I am not sure why it would recognize as card=1.  Do you have a
modprobe option setup forcing it to card=1?

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PULL] http://kernellabs.com/hg/~dheitmueller/950q-fixes

Hello Mauro,

Please PULL from http://kernellabs.com/hg/~dheitmueller/950q-fixes for
the following

au8522: add support for saturation and hue controls
xc5000: return an error on tuning attempts if firmware not loaded

Thanks,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

em28xx DVB modeswitching change: call for testers

Hello all,

I have setup a tree that removes the mode switching code when
starting/stopping streaming.  If you have one of the em28xx dvb
devices mentioned in the previous thread and volunteered to test,
please try out the following tree:

http://kernellabs.com/hg/~dheitmueller/em28xx-modeswitch

In particular, this should work for those of you who reported problems
with zl10353 based devices like the Pinnacle 320e (or Dazzle) and were
using that one line change I sent this week.  It should also work with
Antti's Reddo board without needing his patch to move the demod reset
into the tuner_gpio.

This also brings us one more step forward to setting up the locking
properly so that applications cannot simultaneously open the analog
and dvb side of the device.

Thanks for your help,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DVB support for MSI DigiVox A/D II and KWorld 320U

On Mon, Oct 12, 2009 at 3:23 PM, Lauri Laanmets
lauri.laanm...@proekspert.ee wrote:
 Hello

 I have KWorld 320U USB DVT-T Hybrid and trying to get DVB part working. The
 code from mcentral worked pretty well but as it is closed down now I would
 like to contribute to linux-media and enable and validate the hardware
 support for this device.

 I have:

 Linux 2.6.28-15-generic x86_64 GNU/Linux
 Bus 001 Device 002: ID eb1a:e320 eMPIA Technology, Inc.

 This device has the same id with MSI DigiVox A/D II but I guess it
 shouldn't matter because it appears to be exactly the same thing just with
 the different brand label with Zarlink ZL10353 DVB-T on both boards.

 I have downloaded the code from v4l-dvb and commented out the #if 0 around
 the device dvb definition ( em28xx-cards.c ), also added it to frontend
 registration ( em28xx-dvb.c) the same as KWorld 310 - just a normal Zarlink
 attach function.

 The trouble is that I get an error:

 zl10353_read_register: readreg error (reg=127, ret==-19)

 and I cannot understand why. I have the mcentral code still lying around and
 comparing those codes doesn't seem to have any difference. Maybe there still
 is a magic bit somewhere to set?

In em28xx-dvb.c, try using em28xx_zl10353_with_xc3028_no_i2c_gate in
the dvb_attach() instead of em28xx_zl10353_with_xc3028.
Alternatively, move the case line for your board further down so it's
the same as EM2882_BOARD_TERRATEC_HYBRID_XS instead of being the
same as EM2880_BOARD_KWORLD_DVB_310U

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DVB support for MSI DigiVox A/D II and KWorld 320U

On Mon, Oct 12, 2009 at 4:41 PM, Lauri Laanmets
lauri.laanm...@proekspert.ee wrote:
 Hello

 Tried that but the result is basically the same: zl10353_attach gives

 [  491.490259] zl10353_read_register: readreg error (reg=127, ret==-19)

 And it is funny that if I compile the mcentral latest code in the same
 kernel, it works, but I cannot find the difference in the code :)

 Lauri

Check the dvb_gpio setting in the board profile.  On some of those
boards you need to take put one of the GPO pins high to take the demod
out of reset.  The KWorld 315u and 330u are both like that.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kworld Analog TV 305U without audio - updated

On Mon, Oct 12, 2009 at 5:20 PM, Dênis Goes denish...@gmail.com wrote:
 Hi...

 I updated the driver to latest in repository, but I having audio problems
 yet:

 I'm testing a USB TV Kworld PlusTV Analog TV stick VS-PVR-TV 305U the TV
 video works fine, but without audio...
 
 I tried to pipe the audio via sox:
 tvtime -d /dev/video1  sox -v 1 -V4 -S -t ossdsp /dev/dsp1 -t ossdsp
 /dev/dsp

 -
 But without sucess, sox report follow error:

 sox: SoX v14.2.0
 time:  Dec  1 2008 10:12:25
 issue: Ubuntu jaunty (development branch)
 uname: Linux denis-laptop 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17
 01:57:59 UTC 2009 i686
 gcc:   4.3.3 20081130 (prerelease)
 arch:  1248 48 44 L
 sox oss: OSS driver only supports bytes and words
 sox oss: Forcing to signed linear word

 Input File : '/dev/dsp1' (ossdsp)
 Channels   : 2
 Sample Rate    : 48000
 Precision  : 16-bit
 Sample Encoding: 16-bit Signed Integer PCM
 Endian Type    : little
 Reverse Nibbles: no
 Reverse Bits   : no
 Level adjust   : 1 (linear gain)


 Output File    : '/dev/dsp' (ossdsp)
 Channels   : 2
 Sample Rate    : 48000
 Precision  : 16-bit
 Sample Encoding: 16-bit Signed Integer PCM
 Endian Type    : little
 Reverse Nibbles: no
 Reverse Bits   : no

 sox sox: effects chain: input  48000Hz 2 channels 16 bits (multi)
 sox sox: effects chain: output 48000Hz 2 channels 16 bits (multi)
 In:0.00% 00:00:00.00 [00:00:00.00] Out:0 [  |  ]
 Clip:0    sox sox: /dev/dsp1: lsx_readbuf: Input/output error
 In:0.00% 00:00:00.00 [00:00:00.00] Out:0 [  |  ]
 Clip:0
 Done.

 -
 Follow my dmesg:

 [   59.904056] usb 1-1: new high speed USB device using ehci_hcd and address
 5
 [   60.058312] usb 1-1: configuration #1 chosen from 1 choice
 [   60.180943] em28xx: New device USB 2861 Device @ 480 Mbps (eb1a:e305,
 interface 0, class 0)
 [   60.181035] em28xx #0: chip ID is em2860
 [   60.450213] em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 05 e3 d0 00 5c 00
 6a 22 00 00
 [   60.450223] em28xx #0: i2c eeprom 10: 00 00 04 57 4e 03 00 00 00 00 00 00
 00 00 00 00
 [   60.450231] em28xx #0: i2c eeprom 20: 06 00 01 00 f0 10 01 00 00 00 00 00
 5b 00 00 00
 [   60.450239] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00
 00 00 00 00
 [   60.450246] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00
 [   60.450253] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00
 [   60.450260] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 22 03
 55 00 53 00
 [   60.450268] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 36 00 31 00
 20 00 44 00
 [   60.450275] em28xx #0: i2c eeprom 80: 65 00 76 00 69 00 63 00 65 00 00 00
 00 00 00 00
 [   60.450282] em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00
 [   60.450289] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00
 [   60.450297] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00
 [   60.450304] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00
 [   60.450311] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00
 [   60.450318] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00
 [   60.450325] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00
 [   60.450334] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x28a51142
 [   60.450336] em28xx #0: EEPROM info:
 [   60.450338] em28xx #0:    AC97 audio (5 sample rates)
 [   60.450340] em28xx #0:    500mA max power
 [   60.450342] em28xx #0:    Table at 0x04, strings=0x226a, 0x, 0x
 [   60.450345] em28xx #0: Identified as KWorld DVB-T 305U (card=47)
 [   60.450347] em28xx #0:
 [   60.450348]
 [   60.450351] em28xx #0: The support for this board weren't valid yet.
 [   60.450353] em28xx #0: Please send a report of having this working
 [   60.450355] em28xx #0: not to V4L mailing list (and/or to other
 addresses)
 [   60.450356]
 [   60.458495] tvp5150 1-005c: chip found @ 0xb8 (em28xx #0)
 [   60.468901] tuner 1-0061: chip found @ 0xc2 (em28xx #0)
 [   60.516398] xc2028 1-0061: creating new instance
 [   60.516403] xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner
 [   60.516413] usb 1-1: firmware: requesting xc3028-v27.fw
 [   60.562982] xc2028

Re: Dazzle TV Hybrid USB and em28xx

On Mon, Oct 12, 2009 at 4:49 PM, Giuseppe Borzi gbo...@gmail.com wrote:
 Thanks for your prompt reply. I've downloaded v4l-dvb-5578cc977a13.tar.bz2, 
 but
 it fails to compile when it reaches firedtv-1394.c. The first part of the 
 error
 message is

 /home/gborzi/v4l-dvb-5578cc977a13/v4l/firedtv-1394.c:21:17: error: dma.h: No
 such file or directory
 /home/gborzi/v4l-dvb-5578cc977a13/v4l/firedtv-1394.c:22:21: error: csr1212.h:
 No such file or directory
 /home/gborzi/v4l-dvb-5578cc977a13/v4l/firedtv-1394.c:23:23: error: 
 highlevel.h:
 No such file or directory
 /home/gborzi/v4l-dvb-5578cc977a13/v4l/firedtv-1394.c:24:19: error: hosts.h: No
 such file or directory
 /home/gborzi/v4l-dvb-5578cc977a13/v4l/firedtv-1394.c:25:22: error: ieee1394.h:
 No such file or directory
 /home/gborzi/v4l-dvb-5578cc977a13/v4l/firedtv-1394.c:26:17: error: iso.h: No
 such file or directory
 /home/gborzi/v4l-dvb-5578cc977a13/v4l/firedtv-1394.c:27:21: error: nodemgr.h:
 No such file or directory

Yeah, that happens with Ubuntu Karmic.  The v4l-dvb firedtv driver
depends on headers that are private to ieee1394 and not in their
kernel headers package.

To workaround the issue, open v4l/.config and set the firedtv driver
from =m to =n

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kworld Analog TV 305U without audio - updated

On Mon, Oct 12, 2009 at 5:20 PM, Dênis Goes denish...@gmail.com wrote:
 Hi...

 I updated the driver to latest in repository, but I having audio problems
 yet:

 I'm testing a USB TV Kworld PlusTV Analog TV stick VS-PVR-TV 305U the TV
 video works fine, but without audio...
 
 I tried to pipe the audio via sox:
 tvtime -d /dev/video1  sox -v 1 -V4 -S -t ossdsp /dev/dsp1 -t ossdsp
 /dev/dsp


Just as a test, try opening two console windows, run tvtime in one,
and then once the video is showing run the sox command in the other
window.  I just want to rule out this being some sort of race
condition.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

em28xx mode switching

I was debugging an issue on a user's hybrid board, when I realized
that we are switching the em28xx mode whenever we start and stop dvb
streaming.  We already have the ts_bus_ctrl callback implemented which
puts the device into digital mode and puts it back into suspend
whenever the frontend is opened/closed.

This call seems redundant, and in fact can cause problems if the
dvb_gpio definition strobes the reset pin, as it can put the driver
out of sync with the demodulator's state (in fact this is what I ran
into with the zl10353 - the reset pin got strobed when the streaming
was started but the demod driver's init() routine was not being run
because it already ran when the frontend was originally opened).

The only case I can think of where toggling the device mode when
starting/stopping dvb streaming might be useful is if we wanted to
support being able to do an analog tune while the dvb frontend was
still open but not streaming.  However, this seems like this could
expose all sorts of bugs, and I think the locking would have to be
significantly reworked if this were a design goal.

Thoughts anybody?

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kworld Analog TV 305U without audio - updated

On Mon, Oct 12, 2009 at 6:45 PM, Dênis Goes denish...@gmail.com wrote:
 Hi...

 I was seeing in em28xx-cards.c in KWorld DVB-T 305U section, that is the
 more aproximate model for my card, and I have a doubt, my card is analog
 only (although it's 305U also), but the 305U in em28xx-cards.c have DVB-T,
 can be any parameter for card that causing the problem ?

 Thanks.

It's not clear why the product name says DVB-T since the board
profile that follows doesn't have a DVB-T definition.  Either way,
that's not having an effect on your issue.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dazzle TV Hybrid USB and em28xx

On Mon, Oct 12, 2009 at 7:22 PM, Giuseppe Borzi gbo...@gmail.com wrote:

 Yeah, that happens with Ubuntu Karmic.  The v4l-dvb firedtv driver
 depends on headers that are private to ieee1394 and not in their
 kernel headers package.

 To workaround the issue, open v4l/.config and set the firedtv driver
 from =m to =n

 Devin


 Thanks Devin,
 following your instruction for firedtv I've compiled
 v4l-dvb-5578cc977a13 but the results aren't so good. After doing an
 make rminstall , compiling and make install I plugged the USB
 stick, the various devices were created (including /dev/dvb) and here
 is the dmesg output (now it's identified as card=1)

 then I started checking if it works. The command vlc channels.conf
 works, i.e. it plays the first channel in the list, but is unable to
 switch channel. me-tv doesn't start, but I think this is related to the
 recent gnome upgrade. w_scan doesn't find any channel.

Open v4l/em28xx-cards.c and comment out line 181 so it looks like:

//{EM2880_R04_GPO,0x04,   0xff,  100},/*
zl10353 reset */

This is an issue I have been actively debugging for two other users.

 Analog TV only shows video, no audio. Tried this both with sox and vlc.
 When you say that I have to choose the right TV standard (PAL for my
 region) do you mean I have to select this in the TV app I'm using
 (tvtime, vlc, xawtv) or as a module option? I've not seen any em28xx
 option for TV standard, so I suppose it's in the app.

Correct - the em28xx module does not have module parameters for the
standard - you have to select it in the application.

 Finally, I've noticed that the device is much less hot than it happened
 with out of kernel modules and the card=11 workaround.
 Is your latest post em28xx mode switching related to my device?

Yes, it is one device effected by that discussion.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: No sound in television with Leadtek Winfast USB II Deluxe

2009-10-11 Thread Devin Heitmueller

2009/10/11 Magnus Alm magnus@gmail.com:
 Hi!

 I've been pooking around to get my Leadtek Winfast USB II Deluxe
 working in Ubuntu 9.10 (kernel 2.6.31-12-generic).

 The code for the drivers is collected with:

 hg clone http://linuxtv.org/hg/v4l-dvb


 So far, in television mode, I can tune channels and get picture. But I
 have no sound.
 In Composite mode I have picture and sound, altho it's just black and
 white. (Might depend on my source tho, I haven't put that much time
 into it.)
 In Svideo mode I have sound and color picture, so thats OK.
 To get any sound in tvtime or Xawttv, I have to run sox -r 48000 -c 2
 -t ossdsp /dev/dsp1 -t ossdsp /dev/dsp in a terminal. Only works with
 Composite/Svideo.


 The changes I've made to make it work so far is the following:

 em28xx-cards.c

    { USB_DEVICE(0x0413, 0x6023),
            .driver_info = EM2820_BOARD_LEADTEK_WINFAST_USBII_DELUXE },

 Just for my own convenience, otherwise it finds the
 LEADTEK_WINFAST_USBII device instead, I got bored with doing modprobe
 em28xx card=28 ;-p.


 [EM2820_BOARD_LEADTEK_WINFAST_USBII_DELUXE] = {
        .name         = Leadtek Winfast USB II Deluxe,
        .valid        = EM28XX_BOARD_NOT_VALIDATED,
        .tuner_type   = TUNER_PHILIPS_FM1216ME_MK3,
        .tda9887_conf = TDA9887_PRESENT,
        .decoder      = EM28XX_SAA711X,
        .input        = { {
            .type     = EM28XX_VMUX_TELEVISION,
            .vmux     = SAA7115_COMPOSITE4,
                             */ Was SAA7115_COMPOSITE2 originally */
            .amux     = EM28XX_AMUX_VIDEO,
        }, {
            .type     = EM28XX_VMUX_COMPOSITE1,
            .vmux     = SAA7115_COMPOSITE5,
                             */ Was SAA7115_COMPOSITE0 originally */
            .amux     = EM28XX_AMUX_LINE_IN,
        }, {
            .type     = EM28XX_VMUX_SVIDEO,
            .vmux     = SAA7115_SVIDEO3,
                                  */ Was SAA7115_COMPOSITE0 originally
  */
            .amux     = EM28XX_AMUX_LINE_IN,
        } },



 saa7115.c

 R_08_SYNC_CNTL, 0x28,            /* 0xBO: auto detection, 0x68 = NTSC */

 Changed it from 0x68, so I don't have to switch back to PAL after
 switching input mode. Just for my own convenience.



 When I was searching the internet for information about getting my usb
 tv tuner working, I came across this thread.

 http://thread.gmane.org/gmane.linux.drivers.em28xx/97/focus=124

 (Cut  from the post where the poster got working picture and audio.
 After snooping the device in Windows and parsing the output with
 parser.pl, then playing around with Usbreplay (a tool I don't have
 access to tho, and he was using a em28xx-new build.))

 This line made the video appear:
 000385:  OUT: 01 ms 005258 ms 40 02 00 00 42 00 02 00   02 c4

 And this worked for audio:
 000895:  OUT: 00 ms 006684 ms 40 00 00 00 42 00 01 00   16


 This line made both usb audio and jack audio output of the device work :)


 The video output I fixed with .vmux     = SAA7115_COMPOSITE4, .

 After snooping my device in windows, just swapping between
 television/Composite/Svideo, I didn't get any line with:

 40 00 00 00 42 00 01 00   16

 The only comparable output I found from my snooping is:

 40 00 00 00 42 00 01 00   02

 (Might be because we didn't use the same drivers in Windows, default
 the installation program installs the drivers for Winfast TV USB II,
 doh!.)

 When loading em28xx with reg_debug=1 and doing the same swapping
 between input modes, as I did in windows, with tvtime or xawtv.
 I got the following lines in syslog containing 40 00 00 00 42 00 01
 00 after every input mode switch.

 [ 2548.560012] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00  02
 [ 2548.584049] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00  04
 [ 2548.608014] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00  06
 [ 2548.632012] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00  36
 [ 2548.656012] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00  38
 [ 2548.732012] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00  14
 [ 2548.756012] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00  10
 [ 2548.780012] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00  0c
 [ 2548.804013] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00  0e
 [ 2548.828012] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00  12
 [ 2548.852013] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00  16
 [ 2548.876012] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00  18
 [ 2548.900012] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00  26
 [ 2548.924009] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00  2a
 [ 2548.948012] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00  32
 [ 2548.972013] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00  02

 This might not be the source of my problem, since it both starts and
 ends with  02, but the em28xx driver seems to be unnecessarily
 chatty to me.
 There is much more difference's between the logs than that tho, added
 examples from each log as attachments,

Re: 2.6.32 dvbdev error / Cinergy XS [0ccd:0043]

2009-10-11 Thread Devin Heitmueller

On Sun, Oct 11, 2009 at 4:06 AM, Michael G miga_m...@gmx.de wrote:
 Am Samstag, 10. Oktober 2009 23:48:37 schrieb Devin Heitmueller:
 On Sat, Oct 10, 2009 at 4:19 PM, Michael G miga_m...@gmx.de wrote:
  Hi,
  can someone please help me to get my
  Cinergy XS (Bus 001 Device 010: ID 0ccd:0043 TerraTec Electronic GmbH)
  to run in a 2.6.32 RC3 gentoo system?
 
  When I use the in-kernel driver I'll get the following output:
  usb 1-1: new high speed USB device using ehci_hcd and address 10
  usb 1-1: configuration #1 chosen from 1 choice
  em28xx: New device TerraTec Electronic GmbH Cinergy T USB XS @ 480 Mbps
  (0ccd:0043, interface 0, class 0)
  em28xx #0: chip ID is em2870
  em28xx #0: i2c eeprom 00: 1a eb 67 95 cd 0c 43 00 c0 12 81 00 6a 24 8e 34
  em28xx #0: i2c eeprom 10: 00 00 06 57 02 0c 00 00 00 00 00 00 00 00 00 00
  em28xx #0: i2c eeprom 20: 44 00 00 00 f0 10 01 00 00 00 00 00 5b 00 00 00
  em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 ee 2d 46 4a
  em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 24 03 43 00 69 00
  em28xx #0: i2c eeprom 70: 6e 00 65 00 72 00 67 00 79 00 20 00 54 00 20 00
  em28xx #0: i2c eeprom 80: 55 00 53 00 42 00 20 00 58 00 53 00 00 00 34 03
  em28xx #0: i2c eeprom 90: 54 00 65 00 72 00 72 00 61 00 54 00 65 00 63 00
  em28xx #0: i2c eeprom a0: 20 00 45 00 6c 00 65 00 63 00 74 00 72 00 6f 00
  em28xx #0: i2c eeprom b0: 6e 00 69 00 63 00 20 00 47 00 6d 00 62 00 48 00
  em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x339064dc
  em28xx #0: EEPROM info:
  em28xx #0:      No audio on board.
  em28xx #0:      500mA max power
  em28xx #0:      Table at 0x06, strings=0x246a, 0x348e, 0x
  em28xx #0: Identified as Terratec Cinergy T XS (card=43)
  em28xx #0:
 
  em28xx #0: The support for this board weren't valid yet.
  em28xx #0: Please send a report of having this working
  em28xx #0: not to V4L mailing list (and/or to other addresses)
 
  Chip ID is not zero. It is not a TEA5767
  tuner 0-0060: chip found @ 0xc0 (em28xx #0)
  xc2028 0-0060: creating new instance
  xc2028 0-0060: type set to XCeive xc2028/xc3028 tuner
  usb 1-1: firmware: requesting xc3028-v27.fw
  xc2028 0-0060: Loading 80 firmware images from xc3028-v27.fw, type:
  xc2028 firmware, ver 2.7
  xc2028 0-0060: Loading firmware for type=BASE (1), id .
  xc2028 0-0060: Loading firmware for type=(0), id b700.
  SCODE (2000), id b700:
  xc2028 0-0060: Loading SCODE for type=MONO SCODE HAS_IF_4320 (60008000),
  id 8000.
  xc2028 0-0060: Incorrect readback of firmware version.
  xc2028 0-0060: Loading firmware for type=BASE (1), id .
  xc2028 0-0060: Loading firmware for type=(0), id b700.
  SCODE (2000), id b700:
  xc2028 0-0060: Loading SCODE for type=MONO SCODE HAS_IF_4320 (60008000),
  id 8000.
  xc2028 0-0060: Incorrect readback of firmware version.
  em28xx #0: v4l2 driver version 0.1.2
  em28xx #0: V4L2 video device registered as /dev/video1
 
 
  No /dev/dvb, so no DVT-T. I tried to use the latest v4l-dvb but I can't
  compile it:
 
  /root/v4l-dvb/v4l/dvbdev.c: In function 'init_dvbdev':
  /root/v4l-dvb/v4l/dvbdev.c:516: error: 'struct class' has no member named
  'nodename'
  make[3]: *** [/root/v4l-dvb/v4l/dvbdev.o] Error 1
  make[2]: *** [_module_/root/v4l-dvb/v4l] Error 2
  make[2]: Leaving directory `/usr/src/linux-2.6.32-rc3'
  make[1]: *** [default] Error 2
  make[1]: Leaving directory `/root/v4l-dvb/v4l'
  make: *** [all] Error 2
 
  Any help is appreciated!
 
  Thanks,
  Michael

 Hello Michael,

 Don't bother trying to compile the latest v4l-dvb code.  It's not
 supported even in the latest code (and there is presently no work
 going on to add support).

 Devin

 Hi Devin,
 thanks for the info. I'll keep waiting and hoping :)

 Just a quick addition. With 2.6.30 an em28xx-new it runs an the dmesg output
 looks like this:

 usb 1-1: new high speed USB device using ehci_hcd and address 14
 usb 1-1: configuration #1 chosen from 1 choice
 em28xx v4l2 driver version 0.0.1 loaded
 em28xx: new video device (0ccd:0043): interface 0, class 255
 em28xx: device is attached to a USB 2.0 bus
 em28xx #0: Alternate settings: 8
 em28xx #0: Alternate setting 0, max size= 0
 em28xx #0: Alternate setting 1, max size= 0
 em28xx #0: Alternate setting 2, max size= 1448
 em28xx #0: Alternate setting 3, max size= 2048
 em28xx #0: Alternate setting 4, max size= 2304
 em28xx #0: Alternate setting 5, max size= 2580
 em28xx #0: Alternate setting 6

Re: Dazzle TV Hybrid USB and em28xx

2009-10-11 Thread Devin Heitmueller

Hello Giuseppe,

On Sun, Oct 11, 2009 at 12:38 PM, Giuseppe Borzi gbo...@gmail.com wrote:
 Hello to everyone,
 I bought a Dazzle TV Hybrid USB stick some years ago (2006 maybe?) and until
 now I've used out of kernel drivers from M. Rechberger. Here's a webpage about
 the stick

 http://www.lelong.com.my/Auc/List/2009-10DeStd44780009_AUCTION_-#
 Dazzle-TV-Hybrid-USB-stick-Watch-TV-without-Internet-BID-Now.htm
 (this line has been breaked at the sharp # sign)

 The usbid is eb1a:2881.
 The Linux distribution I'm using, Archlinux, has updated the kernel to 
 2.6.31.3
 and I've failed to patch the out of kernel drivers again, so I've tried the in
 kernel em28xx modules.

Make sure you have the latest v4l-dvb code installed.  The changes for
that board went in relatively recently (make sure you do *not* specify
a card= modprobe parameter).

http://linuxtv.org/repo

 But analog TV has no audio (I've tried sox/arecord-aplay),

Make sure you have the correct standard selected.  This sort of thing
often occurs when you are in an area with PAL support but you have the
device configured for NTSC.

 teletext doesn't work (mtt segfaults) and DVB doesn't work too.

Teletext is not supported currently - I did the NTSC VBI support and
am planning on doing the PAL support in the next couple of weeks.

 With me-tv I
 get an error message like Failed to tune to channel and sometimes a
 timeout.

A fix for this was done this week (but hasn't been checked in yet).
Check the linux-media archive for the PCTV 320e thread.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx: new board id [0ccd:10a2]

2009-10-10 Thread Devin Heitmueller

On Sat, Oct 10, 2009 at 12:25 PM, André Richter scorpw...@web.de wrote:
 Hi,

 I've made tests with my TerraTec board:

 Model: TerraTec H5
 Vendor/Product id: [0ccd:10a2].

 Tests made:
     The original em28xx module does not work
     (unknown device).
     Tests made with own em2884 module (code reused
     from em28xx module - kernel 2.6.30): output
     attached as file.

     Registration works up to i2c eeprom check, but
     all eeprom data are 0xff.

     I could not found the right communication in
     the UsbSnoop.log files (1st 50k lines attached).

     All this features do not work:
     - Analog TV / FM Radio
     - DVB-T / DVB-C
     - Composite / S-Video

 Tested-by: André Richter scorpw...@web.de

 Informations from TerraTec:
     USB: Empia em2884
     Decoder: Micronas DRX-K
     Tuner: NXP TDA 18271

 Informations from others:
     Micronas chips -- now from Trident Micro
     DVB Decoder: DRX-39xxKxx (3926KA1 ?)
     Composite:   AVF-4910BA1 ?
     EEPROM:      ACE 24C32 ?
     Chipset:     APB 7202A ?

 I want to help to develop the em28xx module support
 for my device, but I need more understanding of snoop
 file syntax (were I can find the reg address, ...).
 Also, I have no idea to use the tda18271 module for
 em28xx. Please write me, how I can help you.
 You can write me in german or english.

 Regards
 André

Hello André,

The em2884 isn't really the issue here - I can have it working in a
matter of hours if needed.  The problem with this device is the drx-k,
for which there is no driver, and no developer willing to invest the
50-60 hours that would probably be required to reverse engineer it and
write a driver.

Regarding the eeprom - the current code doesn't work because it's a
16-bit eeprom.  Like the em2874, the eeprom parsing code should be
skipped entirely, since you can end up corrupting the eeprom.

I would suggest you return the device and buy something that is supported.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.32 dvbdev error / Cinergy XS [0ccd:0043]

2009-10-10 Thread Devin Heitmueller

On Sat, Oct 10, 2009 at 4:19 PM, Michael G miga_m...@gmx.de wrote:
 Hi,
 can someone please help me to get my
 Cinergy XS (Bus 001 Device 010: ID 0ccd:0043 TerraTec Electronic GmbH)
 to run in a 2.6.32 RC3 gentoo system?

 When I use the in-kernel driver I'll get the following output:
 usb 1-1: new high speed USB device using ehci_hcd and address 10
 usb 1-1: configuration #1 chosen from 1 choice
 em28xx: New device TerraTec Electronic GmbH Cinergy T USB XS @ 480 Mbps
 (0ccd:0043, interface 0, class 0)
 em28xx #0: chip ID is em2870
 em28xx #0: i2c eeprom 00: 1a eb 67 95 cd 0c 43 00 c0 12 81 00 6a 24 8e 34
 em28xx #0: i2c eeprom 10: 00 00 06 57 02 0c 00 00 00 00 00 00 00 00 00 00
 em28xx #0: i2c eeprom 20: 44 00 00 00 f0 10 01 00 00 00 00 00 5b 00 00 00
 em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 ee 2d 46 4a
 em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 24 03 43 00 69 00
 em28xx #0: i2c eeprom 70: 6e 00 65 00 72 00 67 00 79 00 20 00 54 00 20 00
 em28xx #0: i2c eeprom 80: 55 00 53 00 42 00 20 00 58 00 53 00 00 00 34 03
 em28xx #0: i2c eeprom 90: 54 00 65 00 72 00 72 00 61 00 54 00 65 00 63 00
 em28xx #0: i2c eeprom a0: 20 00 45 00 6c 00 65 00 63 00 74 00 72 00 6f 00
 em28xx #0: i2c eeprom b0: 6e 00 69 00 63 00 20 00 47 00 6d 00 62 00 48 00
 em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x339064dc
 em28xx #0: EEPROM info:
 em28xx #0:      No audio on board.
 em28xx #0:      500mA max power
 em28xx #0:      Table at 0x06, strings=0x246a, 0x348e, 0x
 em28xx #0: Identified as Terratec Cinergy T XS (card=43)
 em28xx #0:

 em28xx #0: The support for this board weren't valid yet.
 em28xx #0: Please send a report of having this working
 em28xx #0: not to V4L mailing list (and/or to other addresses)

 Chip ID is not zero. It is not a TEA5767
 tuner 0-0060: chip found @ 0xc0 (em28xx #0)
 xc2028 0-0060: creating new instance
 xc2028 0-0060: type set to XCeive xc2028/xc3028 tuner
 usb 1-1: firmware: requesting xc3028-v27.fw
 xc2028 0-0060: Loading 80 firmware images from xc3028-v27.fw, type: xc2028
 firmware, ver 2.7
 xc2028 0-0060: Loading firmware for type=BASE (1), id .
 xc2028 0-0060: Loading firmware for type=(0), id b700.
 SCODE (2000), id b700:
 xc2028 0-0060: Loading SCODE for type=MONO SCODE HAS_IF_4320 (60008000), id
 8000.
 xc2028 0-0060: Incorrect readback of firmware version.
 xc2028 0-0060: Loading firmware for type=BASE (1), id .
 xc2028 0-0060: Loading firmware for type=(0), id b700.
 SCODE (2000), id b700:
 xc2028 0-0060: Loading SCODE for type=MONO SCODE HAS_IF_4320 (60008000), id
 8000.
 xc2028 0-0060: Incorrect readback of firmware version.
 em28xx #0: v4l2 driver version 0.1.2
 em28xx #0: V4L2 video device registered as /dev/video1


 No /dev/dvb, so no DVT-T. I tried to use the latest v4l-dvb but I can't
 compile it:

 /root/v4l-dvb/v4l/dvbdev.c: In function 'init_dvbdev':
 /root/v4l-dvb/v4l/dvbdev.c:516: error: 'struct class' has no member named
 'nodename'
 make[3]: *** [/root/v4l-dvb/v4l/dvbdev.o] Error 1
 make[2]: *** [_module_/root/v4l-dvb/v4l] Error 2
 make[2]: Leaving directory `/usr/src/linux-2.6.32-rc3'
 make[1]: *** [default] Error 2
 make[1]: Leaving directory `/root/v4l-dvb/v4l'
 make: *** [all] Error 2

 Any help is appreciated!

 Thanks,
 Michael

Hello Michael,

Don't bother trying to compile the latest v4l-dvb code.  It's not
supported even in the latest code (and there is presently no work
going on to add support).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Hauppage WinTV-HVR-900H

2009-10-09 Thread Devin Heitmueller

On Fri, Oct 9, 2009 at 5:34 AM, Ali Abdallah al...@xfce.org wrote:
 Okay, i installed the latest drivers+the firmware of the device using
 extract_xc3028.pl, the device seems to be detected now, i can detect all the
 analog TV of my cable using tvtime, but manually, i mean i had to disable
 signal detection when scanning, otherwise i got no results, since the
 picture quality is terrible.

 Of course i'm sure that all the connections (cable to antenna, cable to the
 usb stick, ...) are correct, since it works with my old PC equipped with a
 PCI TV card.

 Any advice, what could be the problem? firmware? since you said (you added
 support for this device) should i open a bug report? is this device reported
 as working by other users?

 Please help if possible, almost two weeks with no real success.

Could you please provide a screen shot of the tvtime output?

Also, are you trying to capture over-the-air or are you capturing
cable television?

What analog standard are you using?  PAL-BG?

Did you make sure to tell tvtime which analog standard you are using?

Could you try the S-Video or composite input and see if the picture
quality is still bad (as this well help isolate whether it's a problem
with the tuner chip or the decoder.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Hauppage WinTV-HVR-900H

2009-10-09 Thread Devin Heitmueller

On Fri, Oct 9, 2009 at 1:22 PM, Ali Abdallah al...@xfce.org wrote:
 Screenshots here for TV and S-Video input configuration with TV time.

 http://ali.blogsite.org/files/tvtime/

 Could you try the S-Video or composite input and see if the picture
 quality is still bad (as this well help isolate whether it's a problem
 with the tuner chip or the decoder.


 Same picture quality with S-Video, but with composite there is no picture.

Ok, this helps alot.  This rules out the tuner and suggests that
perhaps the video decoder is not being programmed properly.

Could you please send me the output of dmesg?  I'll see about
setting up a tree with some additional debugging for you to try out.

Thanks,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Pinnace 320e (PCTV Hybrid Pro Stick) support

2009/10/8 Miroslav Pragl lists.subscri...@pragl.cz:
 Hello,
 are here users of Pinnace 320e (PCTV Hybrid Pro Stick)?

 I have lots of problems with tuning, namely
 - scan somehow locks on the first frequency listed in scan file and finds no
 signal on subsequent freqs
 - kaffeine which has own scanning scans RELIABLY two, somehow three of four
 channels available in my region
 - vlc which has great commandline parameters for direc tuning frequency and
 programm (by its ID) works fine

 I currently use Fedora 11 with latest stable kernel (64 bit) and try to keep
 up-to-date with linuxtv drivers

 any help or atleast bug confirming would help me a lot

 Thanks

 MP

 P.S. although i hated the aggressivnes of Markus' drivers from mcentral.de
 (no longer maintained) and need of FULL kernel sources these atleast worked
 :(

Hi Miroslav,

I did the 320e work with the assistance of a couple of users in
Europe.  Could you confirm that you are running the latest v4l-dvb
tree from http://linuxtv.org/hg/v4l-dvb?  If so, please provide the
output of dmesg after connecting the device.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Hauppage WinTV-HVR-900H

On Thu, Oct 8, 2009 at 11:01 AM, Ali Abdallah al...@xfce.org wrote:
 If you're interested in helping the driver development, then take a
 look at the related mailing list posts.  Otherwise, you might be
 better off choosing a different product.

 On the other hand, I think there's been some recent progress on the
 PCTV hybrid pro -- Devin Heitmueller has been doing a lot of work on
 those products lately.  For more information, see
 http://kernellabs.com



 That's a good new, i can still get that card, probably i can help testing
 the driver.

It depends on what your needs are and whether you already own the
device.  If you own an older version of the board already, it may or
may not work depending on which board you ended up with (if you send
the USB ID, I can tell you the status in terms of support).  If you
haven't bought it yet, then the currently shipping version of this
product is not supported (I'm actively working on the support).  Also,
even once I have added the support, it will only be for the digital
part of the card, with no plans at this time to do the analog support.

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: TM6010 driver and firmware

On Thu, Oct 8, 2009 at 4:50 AM, Jan-Simon Möller dl...@gmx.de wrote:
 Hi !

 Using the 3.7 firmware on HVR900H, I get up to this point:

 http://pastebin.ca/1603643

 [...]
 Error during zl10353_attach!
 tm6000: couldn't attach the frontend!
 xc2028 4-0061: destroying instance
 tm6000: Error -1 while registering
 tm6000: probe of 1-5.1:1.0 failed with error -1
 usbcore: registered new interface driver tm6000
 Original value=255


 Best,
 Jan-Simon

I keep seeing people trying out that driver, apparently thinking that
they just need to compile the correct tree in order for their product
to work.  For the record, this driver is currently *TOTALLY BROKEN*.
Unless you are a developer who is prepared to reverse engineer the
wire protocol and debug the driver, then you should not be wasting
your time compiling the tree in the hope that it will work for you.

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Hauppage WinTV-HVR-900H

On Thu, Oct 8, 2009 at 2:20 PM, Ali Abdallah al...@xfce.org wrote:
 I have the card since alsmost 3 years, it never worked, but now i'm in
 urgent need of getting an analog usb stick to work with Linux.

 The PCTV hybrid:

 Bus 001 Device 004: ID eb1a:2881 eMPIA Technology, Inc.

 Thanks for you support, but i need an analog usb stick, well hopefully the
 wintv 900H will get supported soon.

Well, I added support for that device last month, so I would suggest
you install the latest v4l-dvb code from
http://linuxtv.org/hg/v4l-dvb.  Directions can be found here:

http://linuxtv.org/repo

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Pinnace 320e (PCTV Hybrid Pro Stick) support

On Thu, Oct 8, 2009 at 2:13 PM, SebaX75 seba...@yahoo.it wrote:
 Hi Devin,
 we have already discussed a few weeks ago on IRC; you've tryed to identify
 the problem with my help and debug on, but no information about the problem
 was identified, so you have requested to me a log captured with usbmon
 during scanning.
 I've sent you a session captured with usbmon, but after this I've not seen
 any improvement and I've not received any reply.
 In the past day I'm joined on #linuxtv, but probably you was busy and so I
 don't know if there are news.

 Bye and thanks,
 Sebastian

Doh.  You're right.  I completely forgot about that.  Let me look at
the capture and see what is going on.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Pinnace 320e (PCTV Hybrid Pro Stick) support