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 notice
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
entirely
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
terrestrial
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 to
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 become
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 (which seems to be a
2011/12/7 Patrick Dickey pdickeyb...@gmail.com:
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
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).
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 signalled.
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
by the
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
device 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, tunneling, etc
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
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 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 because your latency
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. Try to calculate how
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 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 or say
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 a
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
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 is
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 the
upper
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,
for each ioctl that
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 invalid
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 Tue, Dec 6, 2011 at 8:36 PM, Mauro Carvalho Chehab
mche...@redhat.com 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 Tue, Dec 6, 2011 at 7:49 PM, Mark Brown
broo...@opensource.wolfsonmicro.com 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
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 each
Hello,
On 12/03/11 01:37, HoP wrote:
Hi Alan.
2011/12/3 Alan Coxa...@lxorguk.ukuu.org.uk:
On Thu, 1 Dec 2011 15:58:41 +0100
HoPjpetr...@gmail.com wrote:
Hi,
let me ask you some details of your interesting idea (how to
achieve the same functionality as with vtunerc driver):
[...]
The
Hi
2011/12/5 Florian Fainelli f.faine...@gmail.com:
Hello,
On 12/03/11 01:37, HoP wrote:
Hi Alan.
2011/12/3 Alan Coxa...@lxorguk.ukuu.org.uk:
On Thu, 1 Dec 2011 15:58:41 +0100
HoPjpetr...@gmail.com wrote:
Hi,
let me ask you some details of your interesting idea (how to
achieve
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 then
On Mon, Dec 5, 2011 at 9:28 AM, HoP jpetr...@gmail.com wrote:
Hi
2011/12/5 Florian Fainelli f.faine...@gmail.com:
Hello,
On 12/03/11 01:37, HoP wrote:
Hi Alan.
2011/12/3 Alan Coxa...@lxorguk.ukuu.org.uk:
On Thu, 1 Dec 2011 15:58:41 +0100
HoPjpetr...@gmail.com wrote:
Hi,
let me
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 need
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 made if
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 of
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
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
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 ioctl's
Hi Michael
2011/12/5 Michael Krufky mkru...@linuxtv.org:
On Mon, Dec 5, 2011 at 9:28 AM, HoP jpetr...@gmail.com wrote:
Hi
2011/12/5 Florian Fainelli f.faine...@gmail.com:
Hello,
On 12/03/11 01:37, HoP wrote:
Hi Alan.
2011/12/3 Alan Coxa...@lxorguk.ukuu.org.uk:
On Thu, 1 Dec 2011
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 rather
Hi.
2011/12/3 VDR User user@gmail.com:
On Sat, Dec 3, 2011 at 8:13 AM, Andreas Oberritter o...@linuxtv.org 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
Devin,
I perfectly remember your opinion regarding vtuner.
2011/12/3 Devin Heitmueller dheitmuel...@kernellabs.com:
On Sat, Dec 3, 2011 at 12:42 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
On Sat, 3 Dec 2011 09:21:23 -0800
VDR User user@gmail.com wrote:
On Sat, Dec 3, 2011 at 8:13 AM,
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
On Sun, Dec 4, 2011 at 3:22 PM, HoP jpetr...@gmail.com 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:
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:
Hello Alan,
On 03.12.2011 00:19, Alan Cox wrote:
On Thu, 1 Dec 2011 15:58:41 +0100
HoP jpetr...@gmail.com 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
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
with
On Sat, Dec 3, 2011 at 8:13 AM, Andreas Oberritter o...@linuxtv.org 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
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 from CUSE
On Sat, 3 Dec 2011 09:21:23 -0800
VDR User user@gmail.com wrote:
On Sat, Dec 3, 2011 at 8:13 AM, Andreas Oberritter o...@linuxtv.org 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 a...@lxorguk.ukuu.org.uk wrote:
On Sat, 3 Dec 2011 09:21:23 -0800
VDR User user@gmail.com wrote:
On Sat, Dec 3, 2011 at 8:13 AM, Andreas Oberritter o...@linuxtv.org wrote:
You could certainly build a library to reach a different goal. The goal
On 03.12.2011 18:42, Alan Cox wrote:
On Sat, 3 Dec 2011 09:21:23 -0800
VDR User user@gmail.com wrote:
On Sat, Dec 3, 2011 at 8:13 AM, Andreas Oberritter o...@linuxtv.org wrote:
You could certainly build a library to reach a different goal. The goal
of vtuner is to access remote tuners
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
On Sat, 3 Dec 2011 09:21:23 -0800, VDR User user@gmail.com 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
On Sat, Dec 3, 2011 at 3:30 PM, Walter Van Eetvelt
wal...@van.eetvelt.be 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
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 Fri, 02 Dec 2011 09:14:47 -0200, Mauro Carvalho Chehab
mche...@redhat.com 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
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_ioctl(int fd,
[...]
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 debugging a driver,
On Fri, 02 Dec 2011 12:48:35 +0100, Andreas Oberritter o...@linuxtv.org
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
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
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 I
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 maintain
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 wrapper
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 --
On Thu, 1 Dec 2011 15:58:41 +0100
HoP jpetr...@gmail.com 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
Hi Alan.
2011/12/3 Alan Cox a...@lxorguk.ukuu.org.uk:
On Thu, 1 Dec 2011 15:58:41 +0100
HoP jpetr...@gmail.com 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
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
(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 professional
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
2011/12/1 Mauro Carvalho Chehab mche...@redhat.com:
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
On 01-12-2011 17:59, HoP wrote:
2011/12/1 Mauro Carvalho Chehabmche...@redhat.com:
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
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_start(ap,
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:
On Wed, Nov 30, 2011 at 4:38 PM, HoP jpetr...@gmail.com 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
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 announcement
76 matches
Mail list logo
