On 07.12.2011 22:48, Patrick Dickey wrote:
> 4 (and the reason I decided to chime in here). This email sums
> everything up. Mark is pointing out that someone may want to use this in
> a non LAN setting, and they may/will have problems due to the Internet
> (and their specific way of accessing it)
2011/12/7 Patrick Dickey :
> On 12/07/2011 08:01 AM, Andreas Oberritter wrote:
>> On 07.12.2011 14:49, Mark Brown wrote:
>>> On Tue, Dec 06, 2011 at 03:48:27PM +0100, Andreas Oberritter wrote:
On 06.12.2011 15:19, Mark Brown wrote:
>>>
> Your assertatation that applications should ignore t
On 12/07/2011 08:01 AM, Andreas Oberritter wrote:
> On 07.12.2011 14:49, Mark Brown wrote:
>> On Tue, Dec 06, 2011 at 03:48:27PM +0100, Andreas Oberritter wrote:
>>> On 06.12.2011 15:19, Mark Brown wrote:
>>
Your assertatation that applications should ignore the underlying
transport (whic
On 07.12.2011 17:10, Mark Brown wrote:
> You're talking about a purely software defined thing that goes in the
> kernel - it pretty much has to be able to scale to other applications
> even if some of the implementation is left for later. Once things like
> this get included in the kernel they bec
On 07.12.2011 17:10, Mark Brown wrote:
> a simple loopback in the style of FUSE which
> bounces the kernel APIs up to userspace for virtual drivers would make
> sense.
That's exactly what vtunerc is.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message
On Wed, Dec 07, 2011 at 03:01:18PM +0100, Andreas Oberritter wrote:
> Once and for all: We have *not* discussed a generic video streaming
> application. It's only, I repeat, only about accessing a remote DVB API
> tuner *as if it was local*. No data received from a satellite, cable or
> terrestria
On 07.12.2011 14:49, Mark Brown wrote:
> On Tue, Dec 06, 2011 at 03:48:27PM +0100, Andreas Oberritter wrote:
>> On 06.12.2011 15:19, Mark Brown wrote:
>
>>> Your assertatation that applications should ignore the underlying
>>> transport (which seems to be a big part of what you're saying) isn't
>>
On Tue, Dec 06, 2011 at 03:48:27PM +0100, Andreas Oberritter wrote:
> On 06.12.2011 15:19, Mark Brown wrote:
> > Your assertatation that applications should ignore the underlying
> > transport (which seems to be a big part of what you're saying) isn't
> > entirely in line with reality.
> Did you
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
On Tue, Dec 6, 2011 at 7:49 PM, Mark Brown
wrote:
> On Tue, Dec 06, 2011 at 01:01:43PM +0100, Andreas Oberritter wrote:
>> On 06.12.2011 12:21, Mark Brown wrote:
>> > On Mon, Dec 05, 2011 at 09:41:38PM +0100, Andreas Oberritter wrote:
>
>> >> Are you serious? Lower networking layers should be tran
On Tue, Dec 6, 2011 at 8:36 PM, Mauro Carvalho Chehab
wrote:
> On 06-12-2011 12:38, Andreas Oberritter wrote:
>>
>> On 06.12.2011 15:13, Mauro Carvalho Chehab wrote:
>>>
>>> O_NONBLOCK
>>> When opening a FIFO with O_RDONLY or O_WRONLY set:
>>
>> This does not apply.
>
On 06-12-2011 12:38, Andreas Oberritter wrote:
On 06.12.2011 15:13, Mauro Carvalho Chehab wrote:
O_NONBLOCK
When opening a FIFO with O_RDONLY or O_WRONLY set:
This does not apply.
[...]
When opening a block special or character special file that supports
On 06.12.2011 15:19, Rémi Denis-Courmont wrote:
> Le mardi 6 décembre 2011 15:49:11 Andreas Oberritter, vous avez écrit :
>> 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 inva
On 06.12.2011 15:20, Mauro Carvalho Chehab wrote:
> On 06-12-2011 11:49, Andreas Oberritter wrote:
>> On 06.12.2011 14:22, Mauro Carvalho Chehab wrote:
>>> On 05-12-2011 22:07, HoP wrote:
> I doubt that scan or w_scan would support it. Even if it supports,
> that
> would mean that,
On 06.12.2011 15:19, Mark Brown wrote:
> On Tue, Dec 06, 2011 at 01:01:43PM +0100, Andreas Oberritter wrote:
>> On 06.12.2011 12:21, Mark Brown wrote:
>>> On Mon, Dec 05, 2011 at 09:41:38PM +0100, Andreas Oberritter wrote:
>
Are you serious? Lower networking layers should be transparent to th
On 06.12.2011 15:13, Mauro Carvalho Chehab wrote:
> O_NONBLOCK
> When opening a FIFO with O_RDONLY or O_WRONLY set:
This does not apply.
[...]
> When opening a block special or character special file that supports
> non-blocking opens:
>
> If O_NONBLOCK
On 06-12-2011 11:49, Andreas Oberritter wrote:
On 06.12.2011 14:22, Mauro Carvalho Chehab wrote:
On 05-12-2011 22:07, HoP wrote:
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
Le mardi 6 décembre 2011 15:49:11 Andreas Oberritter, vous avez écrit :
> 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.
That's
On Tue, Dec 06, 2011 at 01:01:43PM +0100, Andreas Oberritter wrote:
> On 06.12.2011 12:21, Mark Brown wrote:
> > On Mon, Dec 05, 2011 at 09:41:38PM +0100, Andreas Oberritter wrote:
> >> Are you serious? Lower networking layers should be transparent to the
> >> upper layers. You don't implement VPN
On 06-12-2011 11:35, Andreas Oberritter wrote:
On 06.12.2011 14:10, Mauro Carvalho Chehab wrote:
On 06-12-2011 10:01, Andreas Oberritter wrote:
On 06.12.2011 12:18, Mark Brown wrote:
On Mon, Dec 05, 2011 at 10:20:03PM +0100, Andreas Oberritter wrote:
On 05.12.2011 21:55, Alan Cox wrote:
The
On 06.12.2011 14:22, Mauro Carvalho Chehab wrote:
> On 05-12-2011 22:07, HoP wrote:
>>> 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. Tr
On 06.12.2011 14:10, Mauro Carvalho Chehab wrote:
> On 06-12-2011 10:01, Andreas Oberritter wrote:
>> On 06.12.2011 12:18, Mark Brown wrote:
>>> On Mon, Dec 05, 2011 at 10:20:03PM +0100, Andreas Oberritter wrote:
On 05.12.2011 21:55, Alan Cox wrote:
> The USB case is quite different becaus
On 05-12-2011 22:07, HoP wrote:
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
On 06-12-2011 10:01, Andreas Oberritter wrote:
On 06.12.2011 12:18, Mark Brown wrote:
On Mon, Dec 05, 2011 at 10:20:03PM +0100, Andreas Oberritter wrote:
On 05.12.2011 21:55, Alan Cox wrote:
The USB case is quite different because your latency is very tightly
bounded, your dead device state is
On 06.12.2011 12:21, Mark Brown wrote:
> On Mon, Dec 05, 2011 at 09:41:38PM +0100, Andreas Oberritter wrote:
>> On 05.12.2011 18:39, Mauro Carvalho Chehab wrote:
>
>>> When you put someone via the network, issues like latency, package
>>> drops, IP
>>> congestion, QoS issues, cryptography, tunnel
On 06.12.2011 12:18, Mark Brown wrote:
> On Mon, Dec 05, 2011 at 10:20:03PM +0100, Andreas Oberritter wrote:
>> On 05.12.2011 21:55, Alan Cox wrote:
>>> The USB case is quite different because your latency is very tightly
>>> bounded, your dead device state is rigidly defined, and your loss of
>>>
On Mon, Dec 05, 2011 at 09:41:38PM +0100, Andreas Oberritter wrote:
> On 05.12.2011 18:39, Mauro Carvalho Chehab wrote:
> > When you put someone via the network, issues like latency, package
> > drops, IP
> > congestion, QoS issues, cryptography, tunneling, etc should be taken
> > into account
>
On Mon, Dec 05, 2011 at 10:20:03PM +0100, Andreas Oberritter wrote:
> On 05.12.2011 21:55, Alan Cox wrote:
> > The USB case is quite different because your latency is very tightly
> > bounded, your dead device state is rigidly defined, and your loss of
> > device is accurately and immediately signa
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.
2011/12/3 Alan Cox:
>
> On Thu, 1 Dec 2011 15:58:41 +0100
> HoP wrote:
>
>
> 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
> How can usbip work if networking and usb are so different and what's so
> different between vtunerc and usbip, that made it possible to put usbip
> into drivers/staging?
Where usbip seems to have remained for a long time without actually being
made useful or correct enough to progress. Meanwhile
On 05.12.2011 21:55, Alan Cox wrote:
> The USB case is quite different because your latency is very tightly
> bounded, your dead device state is rigidly defined, and your loss of
> device is accurately and immediately signalled.
>
> Quite different.
How can usbip work if networking and usb are so
The USB case is quite different because your latency is very tightly
bounded, your dead device state is rigidly defined, and your loss of
device is accurately and immediately signalled.
Quite different.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body o
On 05.12.2011 18:39, Mauro Carvalho Chehab wrote:
> On 05-12-2011 12:28, HoP wrote:
>
>>> And here is a new hack.
>>
>> I'm really tired from all those "hack, crap, pigback ..." wordings.
>>
>> What exactly vtuner aproach does so hackish (other then exposing
>> DVB internals, what is every time ma
On 05-12-2011 12:28, HoP wrote:
And here is a new hack.
I'm really tired from all those "hack, crap, pigback ..." wordings.
What exactly vtuner aproach does so hackish (other then exposing
DVB internals, what is every time made if virtualization support is developing)?
The code itself no nee
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.
>>>
>>> 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
> You know - I'm a bit confused. Somebody are pointing on double
> data copying (userspace networked daemon -> kernel -> application)
> issue and another one warn me to not start network connection
> from the kernel. But if it works for NFS or CIFS then it should not
> be so weaky, isn't it?
And t
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,
let me ask you some details of your interesting idea (how to
achieve the same functionality as
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,
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,
>> 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
On Sun, Dec 4, 2011 at 3:22 PM, HoP wrote:
> 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-
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
> While I agree with your more broad view of the issue, I specifically
> talked about VDR. AFAIK Klaus has no intention of adding true
> server/client support to VDR, so for VDR users, this sounds like it
> could be a working solution without the strict limitations of
> streamdev.
So fix Klaus ra
On Sat, Dec 3, 2011 at 3:30 PM, Walter Van Eetvelt
wrote:
>> So you could finally use VDR as a server/client setup using vtuner,
>> right? With full OSD, timer, etc? Yes, I'm aware that streamdev
>> exists. It was horrible when I tried it last (a long time ago) and I
>> understand it's gotten bett
On Sat, 3 Dec 2011 09:21:23 -0800, VDR User wrote:
...
> So you could finally use VDR as a server/client setup using vtuner,
> right? With full OSD, timer, etc? Yes, I'm aware that streamdev
> exists. It was horrible when I tried it last (a long time ago) and I
> understand it's gotten better. But
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 could pot
On 03.12.2011 18:42, 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 library to reach a different goal. The goal
>>> of vtuner is to access remote tuners with any existing program
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 library to reach a different goal. The goal
>> > of vtuner is to access remote tuners with any ex
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 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 c
On 03.12.2011 17:42, Alan Cox wrote:
>> FWIW, the virtual DVB device we're talking about doesn't have any
>> networking capabilities by itself. It only allows to create virtual DVB
>> adapters and to relay DVB API ioctls to userspace in a
>> transport-agnostic way.
>
> Which you can do working fro
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 server/client setup using vtuner,
righ
> FWIW, the virtual DVB device we're talking about doesn't have any
> networking capabilities by itself. It only allows to create virtual DVB
> adapters and to relay DVB API ioctls to userspace in a
> transport-agnostic way.
Which you can do working from CUSE already, as has been pointed out or
wi
Hello Alan,
On 03.12.2011 00:19, Alan Cox wrote:
> 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):
>>
>> [...]
>>
>>> The driver, as proposed, is not really a dri
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):
>>
>> [...]
>>
>> > The driver, as proposed, is not really a driver, as it doesn't
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):
>
> [...]
>
> > The driver, as proposed, is not really a driver, as it doesn't support any
> > hardware. The kernel driv
> What really surprised me badly was that when I read all 54 responses
> I have counted only two real technical answers!!! All rest were about
> POLITICAL issues - code was NACKed w/o any technical discussion.
> Because of fear of possible abusing of driver.
To answer the original question -- abso
On 02.12.2011 19:16, Andreas Oberritter wrote:
> On 02.12.2011 18:49, Rémi Denis-Courmont wrote:
>> Le jeudi 1 décembre 2011 21:59:56 HoP, vous avez écrit :
Kernel code is GPLv2. You can use its code on a GPLv2 licensed library.
>>>
>>> I see. So if you think it is nice to get dvb-core, make a
On 02.12.2011 18:49, Rémi Denis-Courmont wrote:
> Le jeudi 1 décembre 2011 21:59:56 HoP, vous avez écrit :
>>> Kernel code is GPLv2. You can use its code on a GPLv2 licensed library.
>>
>> I see. So if you think it is nice to get dvb-core, make a wrapper around
>> to get it usable in userspace and
Le jeudi 1 décembre 2011 21:59:56 HoP, vous avez écrit :
> > Kernel code is GPLv2. You can use its code on a GPLv2 licensed library.
>
> I see. So if you think it is nice to get dvb-core, make a wrapper around
> to get it usable in userspace and maintain totally same functionality
> by myself then
On 02-12-2011 09:57, HoP wrote:
If you want to disscuss,
No, I don't want. There are architectural issues on your solution. As I said,
from the Kernel POV, just the network drivers is enough to run *any*
client-server
solution on any OS that uses the TCP/IP stack. All streaming applications (
On Fri, 02 Dec 2011 12:48:35 +0100, Andreas Oberritter
wrote:
>> Btw, applications like vdr, vlc, kaffeine and others already implement
>> their
>> own ways to remotelly access the DVB devices without requiring any
>> kernelspace piggyback driver.
>
> Can vdr, vlc, kaffeine use remote tune
[...]
>>> 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
On 02.12.2011 12:14, Mauro Carvalho Chehab wrote:
> On 01-12-2011 20:55, Andreas Oberritter wrote:
>> On 01.12.2011 21:38, Mauro Carvalho Chehab wrote:
>>> I fail to see where do you need to duplicate dvb-core. An userspace
>>> LD_PRELOAD handler that would do:
>>>
>>> int socket;
>>>
>>> int dvb_i
On Fri, 02 Dec 2011 09:14:47 -0200, Mauro Carvalho Chehab
wrote:
> If you're referring to the device name under /dev, a daemon emulating
> a physical device could create Unix sockets under /dev/dvb.
Hmm, how would that work if a real physical device gets added afterward
and udev wants to cr
On 01-12-2011 20:55, Andreas Oberritter wrote:
On 01.12.2011 21:38, Mauro Carvalho Chehab wrote:
I fail to see where do you need to duplicate dvb-core. An userspace
LD_PRELOAD handler that would do:
int socket;
int dvb_ioctl(int fd, unsigned long int request, ...)
{
void *arg;
On 01.12.2011 21:38, Mauro Carvalho Chehab wrote:
> I fail to see where do you need to duplicate dvb-core. An userspace
> LD_PRELOAD handler that would do:
>
> int socket;
>
> int dvb_ioctl(int fd, unsigned long int request, ...)
> {
> void *arg;
> va_list ap;
>
> va_sta
On 01-12-2011 17:59, HoP wrote:
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, as proposed, is not really a driver, as it doesn't sup
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, as proposed, is not really a driver, as it doesn't support
>>> a
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, as proposed, is not really a driver, as it doesn't support any
hardware. The kernel driver would be used to just copy data
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 - worrying about bad boys abusing -
>> the sufficie
Hello,
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 - worrying about bad boys abusing -
> the su
(stripped LKML)
On Thursday 01 December 2011 01:09:28 Andreas Oberritter wrote:
> [..]
> Regarding the kernellabs.com people[3] lobbying against your
> contribution:
> [..]
KernelLabs is not a collections of politicians who want to change the
world together whatever the costs. We are profession
On 30-11-2011 22:09, Andreas Oberritter wrote:
On 30.11.2011 22:38, HoP wrote:
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-m
On 30.11.2011 22:38, HoP wrote:
> 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 announ
On Wed, Nov 30, 2011 at 4:38 PM, HoP wrote:
> 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. Orig
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
Em 22-06-2011 16:18, Rémi Denis-Courmont escreveu:
> Le mercredi 22 juin 2011 15:17:27 Mauro Carvalho Chehab, vous avez écrit :
>>> 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.
Le mercredi 22 juin 2011 15:17:27 Mauro Carvalho Chehab, vous avez écrit :
> > 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.
>
> If you want to do the networking code at userspa
On Sat, Jun 18, 2011 at 8:10 PM, HoP wrote:
> 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
>> This is not a political issue. It is a licensing issue. If you want to use
>> someone's else code, you need to accept the licensing terms that the
>> developers
>> are giving you, by either paying the price for the code usage (on closed
>> source
>> licensing models), or by accepting the licen
On 06/22/2011 05:19 PM, Mauro Carvalho Chehab wrote:
> Em 22-06-2011 11:24, Andreas Oberritter escreveu:
>> On 06/22/2011 03:45 PM, Mauro Carvalho Chehab wrote:
>>> 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,
Em 22-06-2011 11:24, Andreas Oberritter escreveu:
> On 06/22/2011 03:45 PM, Mauro Carvalho Chehab wrote:
>> 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 :
On 06/22/2011 03:45 PM, Mauro Carvalho Chehab wrote:
> 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, HoP escreveu:
>> 2011/6/21 Ma
Em 22-06-2011 11:03, HoP escreveu:
> 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, HoP escrev
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, HoP escreveu:
>> 2011/6/21 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, HoP escreveu:
> 2011/6/21 Mauro Carvalho Chehab :
>> Em 21-06-2011 12:09, Andreas Ob
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, Andreas Oberritter escreveu:
>> On 06/21/2011 04
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, 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 C
On 06/22/2011 02:55 PM, Mauro Carvalho Chehab wrote:
> 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, Andreas Oberritter escreveu:
Em 22-06-2011 09:37, HoP escreveu:
> 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, Andreas Ob
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, Andreas Oberritter escreveu:
> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote:
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, Andreas Oberritter escreveu:
>> On 06/21/2011 03
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, Andreas Oberritter escreveu:
On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote:
> Em 21-06-2011 11:15, Andreas Oberritter escreveu:
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, Andreas Oberritter escreveu:
> On 06/21/2011 03:44 PM, Devin Heitmueller wrote:
>> O
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
>
> 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 that there are still some fundamental bu
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
1 - 100 of 134 matches
Mail list logo
