Hi Andreas
[...]
>>> You don't need to wait for write-only operations. Basically all demux
>>> ioctls are write-only. Since vtunerc is using dvb-core's software demux
>>> *locally*, errors for invalid arguments etc. will be returned as usual.
>>>
>>> What's left is one call to FE_SET_FRONTEND for
Hi Michael
2011/12/5 Michael Krufky :
> On Mon, Dec 5, 2011 at 9:28 AM, HoP wrote:
>> Hi
>>
>> 2011/12/5 Florian Fainelli :
>>> Hello,
>>>
>>>
>>> On 12/03/11 01:37, HoP wrote:
>>>>
>>>> Hi Alan.
>>>
> I doubt that scan or w_scan would support it. Even if it supports, that
> would mean that,
> for each ioctl that would be sent to the remote server, the error code would
> take 480 ms
> to return. Try to calculate how many time w_scan would work with that. The
> calculus is easy:
> see how many i
Hi
2011/12/5 Florian Fainelli :
> Hello,
>
>
> On 12/03/11 01:37, HoP wrote:
>>
>> Hi Alan.
>>
>> 2011/12/3 Alan Cox:
>>>
>>> On Thu, 1 Dec 2011 15:58:41 +0100
>>> HoP wrote:
>>>
>>>> Hi,
>>>>
>&
>> Well, initial report was made on vdr-portal because of our hardware announce,
>> but you can be sure the same is true if server is build on any linux
>> hardware.
>> Here is some note:
>> http://www.vdr-portal.de/board18-vdr-hardware/board84-allgemein/106610-das-neue-netzwerk-client-der-f%C3%BC
Hi,
> Some input from the sideline reading this discussion. As a FreeBSD'er I would
> very much like to see two things happen:
>
> - vtunerc goes into userspace like a client/server daemon pair using CUSE and
> can support _any_ /dev/dvb/adapter, also those created by CUSE itself. That
> means I c
Devin,
I perfectly remember your opinion regarding vtuner.
2011/12/3 Devin Heitmueller :
> On Sat, Dec 3, 2011 at 12:42 PM, Alan Cox wrote:
>> On Sat, 3 Dec 2011 09:21:23 -0800
>> VDR User wrote:
>>
>>> On Sat, Dec 3, 2011 at 8:13 AM, Andreas Oberritter wrote:
>>> > You could certainly build a
Hi.
2011/12/3 VDR User :
> On Sat, Dec 3, 2011 at 8:13 AM, Andreas Oberritter wrote:
>> You could certainly build a library to reach a different goal. The goal
>> of vtuner is to access remote tuners with any existing program
>> implementing the DVB API.
>
> So you could finally use VDR as a serv
Hi Alan.
2011/12/3 Alan Cox :
> On Thu, 1 Dec 2011 15:58:41 +0100
> HoP wrote:
>
>> Hi,
>>
>> let me ask you some details of your interesting idea (how to
>> achieve the same functionality as with vtunerc driver):
>>
>> [...]
>>
>> > Th
[...]
>>> you failed to convince
>>> people
>>> why this can't be implemented on userspace,
>>
>> Wrong. You failed to convince people why this must be implemented in
>> userspace. Even Michael Krufky, who's "only" against merging it, likes
>> the idea, because it's useful.
>
> Sometimes, when I'm
2011/12/1 Mauro Carvalho Chehab :
> On 01-12-2011 12:58, HoP wrote:
>>
>> Hi,
>>
>> let me ask you some details of your interesting idea (how to
>> achieve the same functionality as with vtunerc driver):
>>
>> [...]
>>
>>> The driver
Hi,
let me ask you some details of your interesting idea (how to
achieve the same functionality as with vtunerc driver):
[...]
> The driver, as proposed, is not really a driver, as it doesn't support any
> hardware. The kernel driver would be used to just copy data from one
> userspace
Please s
Hi
> On Wed, 30 Nov 2011 22:38:33 +0100, HoP wrote:
>> I have one big problem with it. I can even imagine that some "bad guys"
>> could abuse virtual driver to use it for distribution close-source
> drivers
>> in the binary blobs. But is it that - worryi
Hi folks.
I need to warn you that my mail is a bit little longer then I would like
to be.But I'm not able to ask my question without some
background information.
On June 19th, I was sending the driver to the Linux-media
mailing list. Original announcement is there:
http://www.spinics.net/lists/l
> If you would like to help me then you can find out correct device name and
> whats needed for that. I mainly see following possibilities;
> * /dev/ttyAnyseeN
> * /dev/ttyDVBN
> * /dev/adapterN/serial
>
/dev/ttyscXN
or
/dev/dvb/adapterX/scN
where X = ordered adapter number
and N = ordered smar
When I2C_WRITE is used the msg[] array contains one element only.
Don't access msg[1] in that case. Also moved rest of msg2[1]
setting to be used only if needed.
Signed-off-by: Honza Petrous
---
diff -r ae517614bf00 drivers/media/dvb/frontends/cxd2820r_core.c
--- a/drivers/media/dvb/frontends/c
Hi Antti
2011/7/23 Antti Palosaari :
> On 07/23/2011 02:01 AM, HoP wrote:
>>
>> 2011/7/23 Antti Palosaari:
>>>
>>> On 07/23/2011 01:47 AM, HoP wrote:
>>>>
>>>> 2011/7/23 Antti Palosaari:
>>>>>
>>>>> On 07/23/2
2011/7/23 Malcolm Priestley :
> On Sat, 2011-07-23 at 01:47 +0200, HoP wrote:
>> 2011/7/23 Antti Palosaari :
>> > On 07/23/2011 02:31 AM, Antti Palosaari wrote:
>> >>
>> >> On 07/23/2011 02:01 AM, HoP wrote:
>> >>>
>> >>> 2011
2011/7/23 Antti Palosaari :
> On 07/23/2011 02:31 AM, Antti Palosaari wrote:
>>
>> On 07/23/2011 02:01 AM, HoP wrote:
>>>
>>> 2011/7/23 Antti Palosaari:
>>>>
>>>> But now I see what you mean. msg2[1] is set as garbage fields in case of
>
2011/7/23 Antti Palosaari :
> On 07/23/2011 01:47 AM, HoP wrote:
>>
>> 2011/7/23 Antti Palosaari:
>>>
>>> On 07/23/2011 01:18 AM, HoP wrote:
>>>>
>>>> In case of i2c write operation there is only one element in msg[] array.
>>>&
2011/7/23 Antti Palosaari :
> On 07/23/2011 01:18 AM, HoP wrote:
>>
>> In case of i2c write operation there is only one element in msg[] array.
>> Don't access msg[1] in that case.
>
> NACK.
> I suspect you confuse now local msg2 and msg that is passed as fun
In case of i2c write operation there is only one element in msg[] array.
Don't access msg[1] in that case.
Signed-off-by: Honza Petrous
--
diff -uBbp cxd2820r_core.c.orig cxd2820r_core.c
--- cxd2820r_core.c.orig2011-07-22 23:31:56.319168405 +0200
+++ cxd2820r_core.c 2011-07-22 23:35
2011/7/10 Rémi Denis-Courmont :
> Le dimanche 10 juillet 2011 13:43:03 Stefan Seyfried, vous avez écrit :
>> Hi all,
>>
>> I patched test_dvr to use DMX_OUT_TSDEMUX_TAP and named it test_tapdmx.
>> Might be useful for others, too :-)
>> This is my first experience with mercurial, so bear with me if
2011/6/22 Mauro Carvalho Chehab :
> Em 22-06-2011 10:13, Andreas Oberritter escreveu:
>> On 06/22/2011 03:03 PM, Mauro Carvalho Chehab wrote:
>>> Em 22-06-2011 09:37, HoP escreveu:
>>>> 2011/6/22 Mauro Carvalho Chehab :
>>>>> Em 21-06-2011 14:38,
2011/6/22 Mauro Carvalho Chehab :
> Em 22-06-2011 09:30, Andreas Oberritter escreveu:
>> On 06/22/2011 02:17 PM, Mauro Carvalho Chehab wrote:
>>> Em 21-06-2011 14:38, HoP escreveu:
>>>> 2011/6/21 Mauro Carvalho Chehab :
>>>>> Em 21-06-2011 12:09, Andr
2011/6/22 Mauro Carvalho Chehab :
> Em 21-06-2011 14:38, HoP escreveu:
>> 2011/6/21 Mauro Carvalho Chehab :
>>> Em 21-06-2011 12:09, Andreas Oberritter escreveu:
>>>> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote:
>>>>> Em 21-06-2011 11:15, Andr
2011/6/22 Markus Rechberger :
>>
>> My very little opinion is that waving GPL is way to the hell. Nobody told me
>> why similar technologies, in different kernel parts are acceptable,
>> but not here.
>>
>
> since a customer was trying to use this module the only feedback I can give
> right now is
2011/6/21 Mauro Carvalho Chehab :
> Em 21-06-2011 12:09, Andreas Oberritter escreveu:
>> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote:
>>> Em 21-06-2011 11:15, Andreas Oberritter escreveu:
On 06/21/2011 03:44 PM, Devin Heitmueller wrote:
> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Ob
2011/6/21 Mauro Carvalho Chehab :
> Em 21-06-2011 08:04, Andreas Oberritter escreveu:
>> On 06/21/2011 03:35 AM, Mauro Carvalho Chehab wrote:
>>> Em 20-06-2011 18:31, HoP escreveu:
>>>> 2011/6/20 Mauro Carvalho Chehab :
>>>>> Em 20-06-2011 17:24, HoP
2011/6/21 Mauro Carvalho Chehab :
> Em 20-06-2011 18:31, HoP escreveu:
>> 2011/6/20 Mauro Carvalho Chehab :
>>> Em 20-06-2011 17:24, HoP escreveu:
>>>> 2011/6/20 Devin Heitmueller :
>>>>> On Mon, Jun 20, 2011 at 3:56 PM, HoP wrote:
>>>>>
Hi Bjørn.
2011/6/21 Bjørn Mork :
> Devin Heitmueller writes:
>
>> Nothing prevents a third-party from writing closed source drivers.
>> What we do *not* think is fair though is that those third parties
>> should be able to take advantage of all the GPL code that makes up the
>> DVB core, and the
2011/6/20 Mauro Carvalho Chehab :
> Em 20-06-2011 17:24, HoP escreveu:
>> 2011/6/20 Devin Heitmueller :
>>> On Mon, Jun 20, 2011 at 3:56 PM, HoP wrote:
>>>> Do you think it is really serious enough reason to prevent of having
>>>> such virtualization dr
2011/6/20 Devin Heitmueller :
> On Mon, Jun 20, 2011 at 3:56 PM, HoP wrote:
>> Do you think it is really serious enough reason to prevent of having
>> such virtualization driver in the kernel?
>>
>> Let check my situation and tell me how I should continue (TBH, I alr
2011/6/20 Devin Heitmueller :
> 2011/6/20 Sébastien RAILLARD (COEXSI) :
>> If I may put my two cents in this discussion regarding the closed source
>> code problem: maybe it could be great to have some closed source drivers
>> making some DVB hardware working better or even allowing more DVB hardwa
Hi Devin.
2011/6/20 Devin Heitmueller :
> 2011/6/20 Rémi Denis-Courmont :
>> Hello,
>>
>> Le dimanche 19 juin 2011 03:10:15 HoP, vous avez écrit :
>>> get inspired by (unfortunately close-source) solution on stb
>>> Dreambox 800 I have made my own i
Hi,
get inspired by (unfortunately close-source) solution on stb
Dreambox 800 I have made my own implementation
of virtual DVB device, based on the same device API.
In conjunction with "Dreamtuner" userland project
[http://code.google.com/p/dreamtuner/] by Ronald Mieslinger
user can create virtua
2011/5/12 Bjørn Mork :
> Andreas Oberritter writes:
>
>> Please try the patches submitted for testing:
>>
>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg31194.html
>
> Ah, great! Thanks. Nothing better than a problem already solved.
Not solved. Andreas did an attempt to solve it (
Hi Pascal,
> I was adding support for a non working version of DVBWorld HD 2104
>
> It is listed on
> http://www.linuxtv.org/wiki/index.php/DVBWorld_HD_2104_FTA_USB_Box as :
>
> =
> for new solution : 2104B (Sharp0169 Tuner)
>
> * STV6110A tuner
> * ST0903 demod
> * Cyrix CY7C68
> That's promising but no cigar:
>
> cat test-cat3.mpeg > zvbi-atsc-cc --ts
>
> just feeds the output of the cat into a file called zvbi-atsc-cc (not
> surprisingly).
Hehe. Sure, it was my mistake. Piping syntax what you tried
later is exactly what I thought :-)
>
> cat test-cat3.mpeg | zvbi-ats
2010/4/17 David Liontooth :
> HoP wrote:
>>
>> 2010/4/17 Devin Heitmueller :
>>
>>>
>>> On Fri, Apr 16, 2010 at 7:19 PM, David Liontooth
>>> wrote:
>>>
>>>>
>>>> I'm using a HVR-1850 in digital mode and get go
2010/4/17 Devin Heitmueller :
> On Fri, Apr 16, 2010 at 7:19 PM, David Liontooth wrote:
>> I'm using a HVR-1850 in digital mode and get good picture and sound using
>>
>> mplayer -autosync 30 -cache 2048 dvb://KCAL-DT
>>
>> Closed captioning works flawlessly with this command:
>>
>> zvbi-atsc-cc
2010/3/25 Jay R. Ashworth :
> - "HoP" wrote:
>> > As a consequence of moving myself into the 21st century by obtaining
>> > cable internet service, I have a new e-mail address:
>> >
>> > awalls md.metrocast.net
>> >
>>
Hi,
> As a consequence of moving myself into the 21st century by obtaining
> cable internet service, I have a new e-mail address:
>
> awalls md.metrocast.net
>
> My radix.net email address will soon cease working.
>
of course it is not my job, but I wonder why you not
stay on old email. In
Hi Chicken
2010/2/7 Chicken Shack :
> Am Sonntag, den 07.02.2010, 19:10 +0100 schrieb HoP:
>> Hi Chicken,
>>
>> >
>> > However I am still alone with the other problem I always stressed:
>> >
>> > When using alevt-dvb (I attached my overworked ver
Hi Chicken,
>
> However I am still alone with the other problem I always stressed:
>
> When using alevt-dvb (I attached my overworked version 1.7.0 in earlier
> mails - please do have a look at it!) the application hangs when you
> decide to switch to a channel that is part of a new transponder.
>
Hi Chicken
>
> Furthermore: If it is technically possible to send and receive, demux
> and multiplex, play and record complete contents of a transponder (i. e.
> multiple TS streams) by using dvbstream or mumudvb (-> 8192 command line
> parameter), then I myself do not see the necessity to extend
2010/1/21 Mauro Carvalho Chehab :
> HoP wrote:
>> Hi Mauro,
>>
>> 2010/1/20 Mauro Carvalho Chehab :
>>> HoP wrote:
>>>> Hi Mauro,
>>>>
>>>> Not to hassle you, I'm sure you're very busy.
>>>>
>>>>
Hi Mauro,
2010/1/20 Mauro Carvalho Chehab :
> HoP wrote:
>> Hi Mauro,
>>
>> Not to hassle you, I'm sure you're very busy.
>>
>> But I'm not yet received a response from you on mail with corrected patch.
>>
>> Your attention would be appr
Hi Mauro,
Not to hassle you, I'm sure you're very busy.
But I'm not yet received a response from you on mail with corrected patch.
Your attention would be appreciated
Regards
/Honza
2009/12/16 HoP :
> Hi Mauro,
>
> 2009/12/15 Mauro Carvalho Chehab :
> [snip]
> The STi7109 also has a frame buffer approach, currently the
> framebuffer is not implemented in this specific case.
> http://osdir.com/ml/linux.fbdev.user/2008-07/msg4.html
>
When you use stb7109 as main cpu for system (like is done
for many linux or os21-based set-top-boxes already), then
y
Hi Manu,
2010/1/14 Manu Abraham :
> Well, the SAA716x is only the PCI Express interface. There is no video
> capture involved in there with the STi7109. It is a full fledged DVB
> STB SOC.
>
> OSD is handled by the STi7109 on that STB.
> http://www.st.com/stonline/products/literature/bd/11660/sti7
> I don't know the details into the USB device, but each of those CAM's
> have bandwidth limits on them and they vary from one CAM to the other.
> Also, there is a limit on the number of simultaneous PID's that which
> you can decrypt.
>
> Some allow only 1 PID, some allow 3. Those are the basic CA
Hi Jonas
> Does anyone know if there's any progress on USB CI adapter support?
> Last posts I can find are from 2008 (Terratec Cinergy CI USB &
> Hauppauge WinTV-CI).
>
> That attempt seems to have stranded with Luc Brosens (who gave it a
> shot back then) asking for help.
>
> The chip manufacture
Hi Mauro,
2009/12/15 Mauro Carvalho Chehab :
[snip]
>
> I'm still missing a driver or a board entry that requires those
> changes. Could you please send it together with this patch series?
>
We are using it in our project. Currently we are in very early
stage of it. We still have some serious is
Hi Mauro,
I have finally found some time for reworking our patch
with regards of notes I got in disscussion.
BTW, I learnt that sending patch for review to original
authors is right thing (tm), so I have added Oliver,
as isl6421.c author, Patrick as flexcop author, Gerd
as cx88/saa7134 author (I
Hi,
2009/12/13 dvblinux :
> I first have to learn what is and how to "create a patch" since I only
> used my vi to modify the source of the driver and then recompiled it...
>
Start from here:
http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches
/Honza
--
To unsubscribe from
Hi
2009/12/11 Karicheri, Muralidharan :
> Hi,
>
> Thanks for the response. One more question that I have is if
> the devices on the two buses can use the same i2c address.
> That is the case for my board. So wondering if this works as
> well.
>
That is IMHO exactly reason of existence such "expan
Hi,
2009/12/10 Karicheri, Muralidharan :
> Hi,
>
> Thanks for the email.
>
> Any idea how i2c drivers can work with this?
>
> Currently in my board, I have adapter id = 1 for main i2c bus. So when this
> mux driver is built into the kernel, I guess I can access it using a
> different adapter id,
Hi,
2009/12/10 Karicheri, Muralidharan :
> Guennadi,
>
> I am not sure if your MT9T031 changes are part of linux-next tree at v4l-dvb.
> If not, can you point me to the latest stack that I can apply on top of
> linux-next tree to get your latest changes for MT9T031 sensor driver?
>
> I plan to d
Hi Ondrej,
2009/12/2 Ondrej Zary :
> On Tuesday 01 December 2009, Petr Vandrovec wrote:
>> Ondrej Zary wrote:
>> > Fix completely broken mute handling radio-sf16fmi.
>> > The sound was muted immediately after tuning in KRadio.
>> > Also fix typos and add SF16-FMP to the texts.
>>
>> I do not have
Hi Hermann,
>> >>
>> >> Attached patch adds two optional (so, disabled by default
>> >> and therefore could not break any compatibility) features:
>> >>
>> >> 1, tone_control=1
>> >> When enabled, ISL6421 overrides frontend's tone control
>> >> function (fe->ops.set_tone) by its own one.
>> >>
>>
Hi Mauro,
thank you for your valued hints. I'm commenting inside
message:
> First of all, please check all your patches with checkpatch, to be sure
> that they don't have any CodingStyle troubles. There are some on your
> patch (the better is to read README.patches for more info useful
> for deve
Hi,
this is my first kernel patch, so all comments are welcome.
Attached patch adds two optional (so, disabled by default
and therefore could not break any compatibility) features:
1, tone_control=1
When enabled, ISL6421 overrides frontend's tone control
function (fe->ops.set_tone) by its own on
Seems your installed ffmpeg libavcodec library
has no support for PAFF+spatial. Check if update
of such library can help.
Good starting point for PAFF understanging:
http://forum.doom9.org/showthread.php?p=927675
and mplayer with PAFF:
http://forum.doom9.org/archive/index.php/t-130797.html
/Honz
64 matches
Mail list logo
