Hi Ezequiel,
After going through trouble and half with trying to get the following
correspondence through linux-media (...):
Who' calling this ^ ?
Oops. Should it be video_device_release (not tw686x_video_device_release)
and then should keep the line vdev->release = video_device
The T230C v2 hardware needs a mode of the si2168 chip to be
set for which the si2168 driver previously had no support.
This patch uses a specific measure to configure this on the
T230C v2 hardware only - see the flag passed via the ts_mode
attribute and its dependency on USB_PID_MYGICA_T230C2.
Sig
On 7/17/19 9:25 PM, Sean Young wrote:
On Wed, Jul 17, 2019 at 08:11:50PM +0200, Jan Pieter van Woerkom wrote:
The T230C v2 hardware needs a mode of the si2168 chip to be
set for which the si2168 driver previously had no support.
This patch uses a specific measure to configure this on the
T230
On Wed, Jul 17, 2019 at 08:11:50PM +0200, Jan Pieter van Woerkom wrote:
> The T230C v2 hardware needs a mode of the si2168 chip to be
> set for which the si2168 driver previously had no support.
> This patch uses a specific measure to configure this on the
> T230C v2 hardware only - see the flag pa
The T230C v2 hardware needs a mode of the si2168 chip to be
set for which the si2168 driver previously had no support.
This patch uses a specific measure to configure this on the
T230C v2 hardware only - see the flag passed via the ts_mode
attribute and its dependency on USB_PID_MYGICA_T230C2.
Sig
Adds support for the "Mygica T230C v2" into the "dvbsky" driver.
Signed-off-by: Jan Pieter van Woerkom
Tested-by: Frank Rysanek
---
diff -ru a/drivers/media/usb/dvb-usb-v2/dvbsky.c
b/drivers/media/usb/dvb-usb-v2/dvbsky.c
--- a/drivers/media/usb/dvb-usb-v2/dvbsky.c 2019-07-08 00:41:56.00
Add support for the "Mygica T230C v2" into the "dvbsky" driver.
A small enhancement in the si2168 demodulator driver is also
needed, and a USB device ID in dvb-usb-ids.h .
This is v3.6 of proposed patch, based on work from an
anonymous author, and with feedback from Sean Young and
Antti Palosaari.
You should direct this message to majord...@vger.kernel.org :)
On Tue, Jan 8, 2019 at 4:36 PM Bhanu Murthy V wrote:
>
> unsubscribe linux-media
> ---
> This email message is for the sole use of
unsubscribe linux-media
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If
Please don't do that
I reply the
Re: [PATCHv4 00/10] As was discussed here (among other places):
talking about the disadvantage of using the buffer tag, driver won't
aware which buffer will be used for current picture unless all the
previous work are done.
On 1/7/19 7:36 PM, Hans Verkuil
Greetings, my victim.
I know your password - 123456
This is my last warning.
I write you inasmuch as I set a trojan on the internet page with pornography
which you have visited.
My spyware grabbed all your personal information and switched on your webcam
which caught the process of one's mastur
support in the Linux Kernel
due to 'complex camera' devices.
- Dell Latitude 5285 is the first known to have this issue:
``Re: Webcams not recognized on a Dell Latitude 5285 laptop``:
https://www.spinics.net/lists/linux-media/msg131388.html
``[RESEND GIT PULL for 4
FYI: About My Previous Message
Hi,
Am Mrs Patricia William, i just want to know if you receive my
previous email i sent to you last three (3) days ago.
Is your email still Active? If YES; please can you email me back,
i have something very important to discuss with you.
Awaits your reply soon
obviously. I don't know
> if
> Songjun can answer as he's not with Microchip anymore.
Update on this patch:
Boris took the second patch of the series through NAND/MTD tree so this
one can go alone upstream through the linux-media tree.
I also have the 2 required Ack.
So, do you wa
L: linux-...@vger.kernel.org
S:Supported
F:drivers/i2c/busses/i2c-at91.c
-ATMEL ISI DRIVER
-M: Ludovic Desroches
-L: linux-media@vger.kernel.org
-S: Supported
-F: drivers/media/platform/atmel/atmel-isi.c
-F: include/media/atmel-isi.h
-
ATMEL LCDFB DRIVER
gt;
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a7d10a2bb980..65c4b59b582f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2353,13 +2353,6 @@ L: linux-...@vger.kernel.org
> S: Supported
> F: drivers/i2c/busses/i2c-at91.c
>
> -ATMEL ISI DRIVER
> -M:
sses/i2c-at91.c
-ATMEL ISI DRIVER
-M: Ludovic Desroches
-L: linux-media@vger.kernel.org
-S: Supported
-F: drivers/media/platform/atmel/atmel-isi.c
-F: include/media/atmel-isi.h
-
ATMEL LCDFB DRIVER
M: Nicolas Ferre
L: linux-fb...@vger.kernel.org
@@ -9102,1
On 2017-08-09 17:01, Patchwork wrote:
> Hello,
>
> The following patches (submitted by you) have been updated in patchwork:
>
> * linux-media: [2/3,media] cx231xx: drop return value of
> cx231xx_i2c_unregister
> - http://patchwork.linuxtv.org/patch/42858/
> -
Hello!
I googled some time now, but I couldn't find a suitable DKMS to encapsulate
the media-build.
Before I write my own one I would like to ask if it is already existing(for
the case I can't properly use Google).
If not I will use "media-build-experimental-dkms" as a start.
BR,
Jasmin
Hello!
It is now 6,5 years since this eMail ir reply to and a lot of things changed
since then.
As there is currently a lot of effort done to get the newest version of the DD
(Digital Devices) drivers into the Kernel, I want to bring up this topic again.
Yes, this eMail is long but it is necessar
Hi!
> > > The following patches (submitted by you) have been updated in patchwork:
> > >
> > > * linux-media: [RFC,07/13] v4l2: device_register_subdev_nodes: allow
> > > calling multiple times
> > > - http://patchwork.linuxtv.org/patch/39403/
Hi Pavel,
On Thu, Jun 22, 2017 at 05:19:03PM +0200, Pavel Machek wrote:
> Hi!
>
>
> > The following patches (submitted by you) have been updated in patchwork:
> >
> > * linux-media: [RFC,07/13] v4l2: device_register_subdev_nodes: allow
> > calli
Em Thu, 22 Jun 2017 17:19:03 +0200
Pavel Machek escreveu:
> Hi!
>
>
> > The following patches (submitted by you) have been updated in patchwork:
> >
> > * linux-media: [RFC,07/13] v4l2: device_register_subdev_nodes: allow
> > calling multiple times
> &
Hi!
> The following patches (submitted by you) have been updated in patchwork:
>
> * linux-media: [RFC,07/13] v4l2: device_register_subdev_nodes: allow calling
> multiple times
> - http://patchwork.linuxtv.org/patch/39403/
> - for: Linux Media kernel patches
>
low, "superseded" means, that either a
> > newer version of the patch is available, or it's been included in a pull
> > request. Since I don't see a newer version, I should assume, that it's
> > been included in a pull request. However, I don't see
7;s been included in a pull
> request. Since I don't see a newer version, I should assume, that it's
> been included in a pull request. However, I don't see one on linux-media
> either. How am I supposed to track such patch status changes?
>
> Thanks
> Guennadi
>
Hi,
According to the explanations below, "superseded" means, that either a
newer version of the patch is available, or it's been included in a pull
request. Since I don't see a newer version, I should assume, that it's
been included in a pull request. However, I don
e link.
>
> Regards,
> Mauro
--
Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
used as reference for the Request API status update discussions.
Regards,
Mauro
--
Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
This is the draft of the media summit report. I'll be soon posting an online
version of it, with the group photo, at linuxtv.org.
Please review. Also, for the ones that presented a slide deck there, please
send me the slides, for me to post there too.
Thanks!
Mauro
---
Linux Media Summit
Em Sat, 05 Mar 2016 10:54:58 -0500
Michael Ira Krufky escreveu:
> On Sat, Mar 5, 2016 at 10:08 AM, Mauro Carvalho Chehab
> wrote:
> > As discussed on our IRC #v4l channel at Freenode, we'll be running a 1-day
> > Linux Media Summit in San Diego on Aug, 7, just after
On Sat, Mar 5, 2016 at 10:08 AM, Mauro Carvalho Chehab
wrote:
> As discussed on our IRC #v4l channel at Freenode, we'll be running a 1-day
> Linux Media Summit in San Diego on Aug, 7, just after the Embedded
> Linux Conference.
>
> Feel free to submit relevant topics related
As discussed on our IRC #v4l channel at Freenode, we'll be running a 1-day
Linux Media Summit in San Diego on Aug, 7, just after the Embedded
Linux Conference.
Feel free to submit relevant topics related to the Linux Kernel support
for media, in order to help us to build the workshop
ll be in Dublin the next week for
>>>the ELCE, unfortunately, this year we will not have the linux-media
>>>summit, because it will be in Korea.
>>>
>>>Anyway, I think that it can be a great idea to meet in Dublin and
>have
>>>dinner together.
>>&
Hi,
2015-10-02 14:32 GMT+02:00 Hans Verkuil :
> On October 2, 2015 12:05:37 PM GMT+01:00, Ricardo Ribalda Delgado
> wrote:
>>Hello
>>
>>Some of the people from this list will be in Dublin the next week for
>>the ELCE, unfortunately, this year we will not have the
On October 2, 2015 12:05:37 PM GMT+01:00, Ricardo Ribalda Delgado
wrote:
>Hello
>
>Some of the people from this list will be in Dublin the next week for
>the ELCE, unfortunately, this year we will not have the linux-media
>summit, because it will be in Korea.
>
>Anyway, I t
Hello
Some of the people from this list will be in Dublin the next week for
the ELCE, unfortunately, this year we will not have the linux-media
summit, because it will be in Korea.
Anyway, I think that it can be a great idea to meet in Dublin and have
dinner together.
At least these people will
会员电影www.rjdon6di5.13131a.comN�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ&�)ߡ�a���� �G���h��j:+v���w��٥
d at
demod-stage.
Any FE can be connected with any FE in any order. Per board different
standards can be demodulated at the same time. For example: FE3 and FE2
are doing DVB-T and FE1 and FE0 DVB-T2 .
--
Patrick.
--
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
rote:
>
> > This is the first draft for the Linux Media Summit Report.
> >
> > Please note that the items 3 to 5 are not in good shape. In special,
> > nobody took Etherpad notes on item 4.
> >
> > Please review. I'll publish a second (final
On 04/22/15 20:31, Mauro Carvalho Chehab wrote:
> This is the first draft for the Linux Media Summit Report.
>
> Please note that the items 3 to 5 are not in good shape. In special,
> nobody took Etherpad notes on item 4.
Item 4 was just me presenting on ongoing projects. As far a
Hi Mauro,
I could not participate at your Summit, but may have an input to the
media-controller in DVB - see below.
On Wed, 22 Apr 2015 15:31:46 -0300 Mauro Carvalho Chehab
wrote:
> This is the first draft for the Linux Media Summit Report.
>
> Please note that the items 3 to 5 a
This is the first draft for the Linux Media Summit Report.
Please note that the items 3 to 5 are not in good shape. In special,
nobody took Etherpad notes on item 4.
Please review. I'll publish a second (final?) draft after having some
feedback.
Regards,
Mauro
-
Linux Media Summit - Marc
Hi Mauro,
On Tue, Dec 23, 2014 at 2:38 PM, Patchwork wrote:
> Hello,
>
> The following patches (submitted by you) have been updated in patchwork:
>
> * linux-media: [1/2] of: Add new compatibles for CODA bindings
> - http://patchwork.linuxtv.org/patch/27149/
>
I am requesting that the following presentation/discussion to be added
to the media mini-summit agenda. The intent is to do a very short
presentation and leave time for discussion.
Linux media power management - problems, challenges and fixes
Media devices can be very complex to support in
Hi,
I have to rebuild the kernel of my Nexus 7 (2013 version).
This is not a problem, except that my dvb dongle is not supported by
the current sources of my 3.4 kernel.
I would like to merge the dvb-usb-v2 directory structure from
linux-media into this kernel tree, but don't know the proc
Am 02.11.2013 17:39, schrieb Mauro Carvalho Chehab:
Em Sat, 02 Nov 2013 14:00:13 +0100
Frank Schäfer escreveu:
Am 31.10.2013 13:13, schrieb Patchwork:
Hello,
The following patch (submitted by you) has been updated in patchwork:
* linux-media: em28xx: make sure that all subdevices are
Em Sat, 02 Nov 2013 14:00:13 +0100
Frank Schäfer escreveu:
> Am 31.10.2013 13:13, schrieb Patchwork:
> > Hello,
> >
> > The following patch (submitted by you) has been updated in patchwork:
> >
> > * linux-media: em28xx: make sure that all subdevice
Am 31.10.2013 13:13, schrieb Patchwork:
> Hello,
>
> The following patch (submitted by you) has been updated in patchwork:
>
> * linux-media: em28xx: make sure that all subdevices are powered on when
> needed
> - http://patchwork.linuxtv.org/patch/20422/
> -
t;
> Date: Tue, 15 Oct 2013 15:58:03 -
> From: Patchwork
> To: rmk+ker...@arm.linux.org.uk
> Subject: [linux-media] Patch notification: 1 patch updated
> Delivery-date: Tue, 15 Oct 2013 16:58:09 +0100
>
> Hello,
>
> The following patch (submitted by you) has been upd
Bad move.
- Forwarded message from Patchwork -
Date: Tue, 15 Oct 2013 15:58:03 -
From: Patchwork
To: rmk+ker...@arm.linux.org.uk
Subject: [linux-media] Patch notification: 1 patch updated
Delivery-date: Tue, 15 Oct 2013 16:58:09 +0100
Hello,
The following patch (submitted by you
Hi all,
GSoC 2014 was announced (http://lwn.net/Articles/569811/), and I was wondering
whether we as linux-media community could come up with a good proposal. If we
want to participate, then we probably need to have something ready by January.
Suggestions are welcome.
Regards,
Hans
ng list
> media-works...@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop
--
Peter
--
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
st years, we'll be using the
> media-works...@linuxtv.org mailing list for such discussions.
I'm very interested in having a media mini-summit in Edinburgh. I'll be
there.
--
Cheers,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from
t; Thank you!
> > --
> >
> > Cheers,
> > Mauro
>
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ou!
> --
>
> Cheers,
> Mauro
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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
such discussions.
I will be in Edinburgh the entire week because of kvm-forum. So I'll try
to join the mini-summit. I don't have anything specific to discuss.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message t
e using the
> media-works...@linuxtv.org mailing list for such discussions.
I'll be there.
Hans
--
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
s.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
subscribe 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
Hi,
Am 27.04.2013 16:51, schrieb Klaus Schmidinger:
On 27.04.2013 14:14, Reinhard Nissl wrote:
Hi,
my stb0899 card works properly on dvb-s and dvb-s2 transponders
when using a direct port on my sat multiswitch.
When using a SCR port on that multiswitch and changing VDR's
config files accordin
my budget cards, and there I indeed can only tune to DVB-S transponders.
No idea how to solve this, though...
Klaus
--
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
can't be fixed, because some software might rely
> on the bug. Oh well...
Unfortunately, yes: fixing driver bugs that break application that
rely on it is a problem. As Linus said on [1]:
"We may have to revert it if things get too nasty,
but we should have done this years and years ago, so let's hope not."
I think we should revert Antti patch, until we're sure that all applications
are capable of working fine with ENOTTY. Only after that, we can remove the
bad usage of EOPNOTSUPP.
> In this particular function of VDR I have now changed things to no longer
> check for any particular "not supported" errno value, just EINTR. I hope
> that one is standardized enough...
Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ged things to no longer
check for any particular "not supported" errno value, just EINTR. I hope
that one is standardized enough...
Klaus
--
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
s USB controller (AMD SBxxx?)?
Easiest way to work around problem is to put these devices to USB port
that are under different USB HCI.
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.
in case ;-)
http://en.wikipedia.org/wiki/KISS_principle
http://www.inspireux.com/2008/07/14/a-designer-achieves-perfection-when-there-is-nothing-left-to-take-away
Klaus
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vg
en-there-is-nothing-left-to-take-away
Klaus
--
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
ys a bar that goes from 0 ("no signal at all") to full extent
("perfect
signal"). So for VDR any value range that can be linearly converted to a range
between 0% and 100% would do just fine. The only important thing is that it is
the *same* for all frontends! Ideally I wou
rrected blocks are not usually reported as rate, instead
just blocks found to be faulty after outer coding. This is counter which
very rarely increases, if you have picture it should remain 0 or at
least near zero, otherwise your picture is totally garbage.
I hate you have added some time
///home/mchehab/stats/Documentation/DocBook/media_api/FE_GET_SET_PROPERTY.html
---
- Frontend Quality of Service/Statistics indicators
Except for DTV_QOS_ENUM, the values are returned via dtv_property.stat.
For most delivery systems, this will return a single value for each parameter.
It
at all. Here we
are talking about making pro grade software based on home grade silicon,
for which most don't have proper documentation.
Manu
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
having the capability to make a pro-grade signal analyzer.
After years of waiting, I don't think half-assing is a good idea.
--
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
(no exact units)
> * measured from inner coding
>
> 4) Quality UCB
> * ~like currently (no exact units)
> * measured from outer coding (naturally)
> * counter is increased over lifetime
> * tune resets counter?
> * driver is responsible of polling statistic in background and report
> from cache
I still think that the better is to provide exact units where available.
Userspace can easily discard whatever scale it is, provided that they're
properly specified (including their typical range). Developers should only
implement the specific range when they're sure about that (e. g.
reverse-engineered drivers will be relative - even for SNR - devices based
on the datasheets can provide real values).
> I would not like to define exact units for BER and USB as those are
> quite hard to implement and also non-sense. User would like just to see
> if there is some (random) numbers and if those numbers are rising or
> reducing when he changes antenna or adjusts gain. We are not making a
> professional signal analyzers - numbers does not need to be 100% correctly.
No, but this API can be used by them or by STB's. So, it should have a way
to be used by professional applications.
> ISDB-T statistics are forced also to that simple API. Calculating
> average value for example. Statistic differences between layers are so
> minor that users does not even care to know.
There's no simple way to merge those values, especially for the error
counters, as it will depend on what program is being displayed.
With regards to signal strength and SNR, Segment 0 information
(the central one) is probably the best shot.
What we can do is to estimate "global" value and put it at data[0] information
for GET_PROPERTIES. This way, simple applications can just use that info.
So, what we can do for ISDB-T "global" QoS measure is:
- Strength and SNR: report the segment 0 value for the "global"
indicator;
- BER, UCB: to sum up the error count of all active segments. This
is a worse case scenario, and the more likely one, as people tend
to watch to the HD program, when available (of course, if the
display hardware has enough resources to decode 1080p).
Keep reporting a per-layer stats. We do have enough space at the data
payload for that.
This way simple applications can just get the first value and don't care
if the standard is ISDB-T.
More sophisticated applications can get all data, and automatically switch
to a lower resolution stream if the QoS is not good enough for HD but
reliable enough for LD.
>
> And as there is some persons who surely like to do QoS API like need of
> $10k professional equipment, I propose to add more accurate reports as
> alternative BUT that minimalist API should be offered even professional
> API exits.
If you agree with this combined proposal, I can write a new patchset.
Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
urely like to do QoS API like need of
$10k professional equipment, I propose to add more accurate reports as
alternative BUT that minimalist API should be offered even professional
API exits.
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
t; layer B = 12
> layer C = 30
>
> an 1-seg LD program will have 0 uncorrected blocks;
> an SD program will have 12 uncorrected error blocks;
> a HD program will have 42 uncorrected error blocks.
>
> It shouldn't be that hard to take it into account on userspace, but
> doing it at kernel level would be very painful, if possible, as
> kernelspace would be required to know what PID's are being shown, in
> order to estimate the error count measures for them. Also, it would
> require a much more complex kernelspace-userspace interface.
Two additional notes:
1) If you want to get further information, it is available on ARIB
STD-B31 spec:
http://www.arib.or.jp/english/html/overview/doc/6-STD-B31v1_6-E2.pdf
There, table 3-2 shows the main characteristics of the modulation;
how the 3 independent channels are handled and fig. 3.4
shows a simplified diagram to give an idea on how the hierarchical TS
packets are broken into the 3 layers
2) There are in the market some narrow-band decoders. Those tunes only
1 segment (440kHz), and are meant to be used on mobile devices that can
receive only LD programs. Only for those devices, it is possible to
offer a single set of statistics (SNR, strength, BER, UCB, etc),
because it can decode just one layer. I have a few of them here,
and we have 2 drivers for those 1-seg devices (s921 and siano).
The full-seg drivers currently provide crappy information or don't
provide any QoS stats at all due to the lack of a proper API.
Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
like that:
layer A - 1 segment for LD programs - modulated using QPSK;
layer B - 3 segments for SD programs - modulated using 16QAM;
layer C - 9 segments for HD programs - modulated using 64QAM.
The TDM TS packets from the Transport Stream are broken into those 3
layer
st that you define this minimal interface and allow applications
to retrieve what they really need. Once this is done, feel free to implement
whatever theoretical bells and whistles you fell like doing - that's all
fine with me, as long as the really important stuff keeps working ;-)
Klaus
-
application. One of the reasons is that, if we
now decide to fix the above, your application will not work as it would be
expected.
> What I would really wish for is that FE_READ_SIGNAL_STRENGTH (which is
> already there)
> would return a *normalized* value in some defined range (
loated API that is probably only of theoretical
value in the first place. It's these two simple, straighforward functions that
are
of practical value. Please make it so the we can finally have a defined
interface
for this!
Klaus
--
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
If this is what this patch is aimed at, I'm all
for it!
Klaus
--
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
Hi all,
As discussed in Barcelona I would write a text describing requirements for new
drivers and what to expect when submitting patches to linux-media.
This is the second rough draft and nothing is fixed yet.
I have incorporated all comments I received after I posted the first version
those driver's patches.
Ok, thanks, I think this should be mentioned in the document.
Regards,
Frank
--
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
Em Tue, 11 Dec 2012 14:15:31 +0100
Hans Verkuil escreveu:
> On Mon 10 December 2012 14:07:09 Hans Verkuil wrote:
> > Hi all,
> >
> > As discussed in Barcelona I would write a text describing requirements for
> > new
> > drivers and what to expect when
en the patch gets merged on my tree, the author will receive
another email.
So, a fake submission can easily be detected.
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Stezenbach (authored
lines:19/172=11%,commits:3/24=12%)
Harvey Harrison (authored lines:18/172=10%)
Robert Schedel (authored lines:16/172=9%)
Andrew Morton (commits:7/24=29%)
Oliver Endriss (commits:6/24=25%)
linux-media@vger.kernel.org (open list:MEDIA INPUT INFRA...)
linux-ker...@vger.kern
it.
> > >
> > > Maybe "the core reviewer" or "the main reviewer" ? Everybody is of course
> > > welcome to review patches, the point here is to state who a good contact
> > > person is when a patch doesn't get reviewed.
> >
> &
On Mon 10 December 2012 14:07:09 Hans Verkuil wrote:
> Hi all,
>
> As discussed in Barcelona I would write a text describing requirements for new
> drivers and what to expect when submitting patches to linux-media.
>
> This is a first rough draft and nothing is fixed yet.
>
w it and add a acked-by or reviewed-by line, but it will not go
> > > > > through the submaintainer's git tree.
> > > > >
> > > > > The platform maintainers are:
> > > > >
> > > > > TDB
> > > >
> > >
a text describing requirements
> > > > for
> > > > new drivers and what to expect when submitting patches to linux-media.
> > > >
> > > > This is a first rough draft and nothing is fixed yet.
> > > >
> > > > I have a few open
is just a small correction, but maybe it can be a little more verbose.
>
> What I meant to say is that, after the merge window, the patches will be
> "postponed for upstream merge until the next merge window".
>
> The original text could give the impression that even at the su
Barcelona I would write a text describing requirements for
> > > new drivers and what to expect when submitting patches to linux-media.
> > >
> > > This is a first rough draft and nothing is fixed yet.
> > >
> > > I have a few open questions:
> > >
ime for the other maintainers and reviewers to double-check the entire
> set of changes for the next Linux version."
>
> (yeah, I know you're talking more about it later, but I think this makes it
> a little clearer that no submissions will typically be accepted so late at
>
uro gets around to
> >> cleaning
> >> out patchwork. Instead the submaintainers can do that themselves and
> >> collect
> >> accepted patches in their git tree and post regular pull requests for
> >> Mauro.
> >>
> >> It should simplify things substantially for Mauro, we hope.
> >>
> >> I think we have enough people doing reviews etc. (although more are always
> >> welcome), it's the patchflow itself that is the problem.
> > Yeah, the issue is that both reviewed, non-reviewed and rejected/commented
> > patches go into the very same queue, forcing me to revisit each patch
> > again,
> > even the rejected/commented ones, and the previous versions of newer
> > patches.
> >
> > By giving rights and responsibilities to the sub-maintainers to manage their
> > stuff directly at patchwork, those patches that tend to stay at patchwork
> > for
> > a long time will likely disappear, and the queue will be cleaner.
>
> So who can get an account / is supposed to access patchwork ?
> - subsystem maintainers ?
> - driver maintainers ?
> - patch creators ?
Subsystem maintainers only, except if someone can fix patchwork, adding
proper ACL's there to allow patch creators to manage their own patches
and sub-system maintainers to delegate work to driver maintainers, without
giving them full rights, and being notified about status changes on
those driver's patches.
The current way patchwork implements it requires a very high degree of trust
between the ones handling patches there, as anyone with access to patchwork
can do bad things there affecting someone's else workflow.
Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
me
>> a lot easier.
>>
>> So the core two changes are 1) giving clear responsibilities to
>> submaintainers
>> and 2) giving submaintainers access to patchwork to keep track of the
>> patches.
>>
>> So patch submitters no longer have to wait until Maur
roject
maintainer can change the patch status, so, delegation doesn't work
if the "delegated user" is not a project owner.
Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Em Mon, 10 Dec 2012 14:07:09 +0100
Hans Verkuil escreveu:
> Hi all,
>
> As discussed in Barcelona I would write a text describing requirements for new
> drivers and what to expect when submitting patches to linux-media.
>
> This is a first rough draft and nothing is fixed
/
--
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
no longer have to wait until Mauro gets around to cleaning
> out patchwork. Instead the submaintainers can do that themselves and collect
> accepted patches in their git tree and post regular pull requests for Mauro.
>
> It should simplify things substantially for Mauro, we hope.
>
> I think we have enough people doing reviews etc. (although more are always
> welcome), it's the patchflow itself that is the problem.
Yeah, the issue is that both reviewed, non-reviewed and rejected/commented
patches go into the very same queue, forcing me to revisit each patch again,
even the rejected/commented ones, and the previous versions of newer patches.
By giving rights and responsibilities to the sub-maintainers to manage their
stuff directly at patchwork, those patches that tend to stay at patchwork for
a long time will likely disappear, and the queue will be cleaner.
Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
r responsibilities to submaintainers
and 2) giving submaintainers access to patchwork to keep track of the patches.
So patch submitters no longer have to wait until Mauro gets around to cleaning
out patchwork. Instead the submaintainers can do that themselves and collect
accepted patches in thei
1 - 100 of 238 matches
Mail list logo
