At Tue, 24 Nov 2009 22:12:36 +0100,
Krzysztof Helt wrote:
>
> From: Krzysztof Helt
>
> This is recreated driver for the FM module found on Miro
> PCM20 sound cards. This driver was removed around the 2.6.2x
> kernels because it relied on the removed OSS module. Now, it
> uses a current ALSA modu
At Wed, 25 Nov 2009 10:13:53 +0100,
I wrote:
>
> At Tue, 24 Nov 2009 22:12:36 +0100,
> Krzysztof Helt wrote:
> >
> > From: Krzysztof Helt
> >
> > This is recreated driver for the FM module found on Miro
> > PCM20 sound cards. This driver was removed around the 2.6.2x
> > kernels because it reli
"Takashi Iwai" pisze:
> At Tue, 24 Nov 2009 22:12:36 +0100,
> Krzysztof Helt wrote:
> >
> > From: Krzysztof Helt
> >
> > This is recreated driver for the FM module found on Miro
> > PCM20 sound cards. This driver was removed around the 2.6.2x
> > kernels because it relied on the removed OSS mod
On Thu, Nov 19, 2009 at 6:15 PM, Kuninori Morimoto
wrote:
> Signed-off-by: Kuninori Morimoto
> ---
>>> Guennadi
>
> I add new number in v4l2-chip-ident.h
> Is it OK for you ?
>
> This camera is very picky.
> So, it have a lot of constant value.
>
> The register of mt9t112 and mt9t111 are same.
>
Mauro,
Please pull from http://linuxtv.org/hg/~pinchartl/v4l-dvb-cleanup/
for the following 10 changesets:
v4l: Add video_device_node_name function
v4l: Use the new video_device_node_name function
v4l: Re
Hi Mauro,
I forgot to combine two patches together in the last request to avoid
bisection issues, so here's a new one (same URL, I've rebased the tree).
Please pull from http://linuxtv.org/hg/~pinchartl/v4l-dvb-cleanup/
for the following 9 changesets:
v4l: Add video_device_node_name function
v4
On Tue, 2009-11-24 at 19:32 -0800, Trent Piepho wrote:
> On Wed, 25 Nov 2009, Maxim Levitsky wrote:
> >
> > Its not the case.
> > There are many protocols, I know that by experimenting with my universal
> > remote. There are many receivers, and all have different accuracy.
> > Most remotes aren't
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following:
- v4l2-dbg: report fail reason to the user
- spec: unexpand initial spaces when generating xml sources
- spec: regenerated xml source files
- spec: remove old
Hi all,
In dvb-spec there are several valgrind patches that add support to valgrind for
the dvb ioctls. However, these patches no longer apply to the latest valgrind
(and probably haven't for a *very* long time), so unless someone wants to port
these to recent valgrind versions I propose to delete
Guennadi Liakhovetski wrote:
On Tue, 24 Nov 2009, Ryan Raasch wrote:
Hello,
I have implemented a driver for the LZ0P374 Sharp CCD camera sensor. I have
been using an old kernel, and now i am updating to the new soc_camera
framework. My question is, is there anyone using this sensor? We bough
This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.
Results of the daily build of v4l-dvb:
date:Wed Nov 25 14:13:22 CET 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset: 13474:fb39ccbd9692
gcc version: gcc (
Mauro,
Please pull from http://linuxtv.org/hg/~pinchartl/uvcvideo/
for the following 5 changesets:
uvcvideo: Add support for Genius eFace 2025 webcams
uvcvideo: Merge iterms, oterms and units linked lists
uvcvideo: Fix extension units parsing
uvcvideo: Refactor chain scan
uvcvideo: Factorize com
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-pms for the
following:
- pms: source code cleanup, use struct v4l2_device.
- pms: convert from V4L1 to V4L2.
It's time to get this merged. I always wanted to allow this driver to be used
with
'cat /dev/video0 >x' instead of
Hopefully CC'ing the au0828, cx231xx, cx23885, s2255 and cx25821 maintainers.
Could you please ack patch http://linuxtv.org/hg/~pinchartl/v4l-dvb-
cleanup/rev/7a762df57149 ? The patch should be committed to v4l-dvb in time
for 2.6.33.
On Wednesday 18 November 2009 13:54:06 Laurent Pinchart wrote
Hi Hermann,
Thanks for your reply. I'm a little lost in what to do next.
How do I force the card to be recongised as card 169 (the compro videomate
S350) instead of card 139?
Thanks,
Dominic
- Original Message
From: hermann pitton
To: Dominic Fernandes
Cc: linux-media@vger.kern
Hopefully tonight I will get a chance to isolate the machine and hook
the incoming cable directly to the mythbox. If it still happens I'll
try isolating the ground.
As far as the history of the machine. This only seemed to appear when
I installed the new Mythbuntu, in previous versions and in windo
On Tue, Nov 24, 2009 at 6:39 PM, Andy Walls wrote:
> BTW, I did a quick skim of your cx18-alsa stuff. I noticed two things:
>
> 1. A memory leak in an error path:
>
> http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2/rev/cb267593943f#l85
>
>
> 2. Technically open_id should probably be
Andy Walls writes:
> I would also note that RC-6 Mode 6A, used by most MCE remotes, was
> developed by Philips, but Microsoft has some sort of licensing interest
> in it and it is almost surely encumbered somwhow:
I don't know about legal problems in some countries but from the
technical POV han
On Wednesday 25 November 2009 17:21:26 Laurent Pinchart wrote:
> Hopefully CC'ing the au0828, cx231xx, cx23885, s2255 and cx25821 maintainers.
>
> Could you please ack patch http://linuxtv.org/hg/~pinchartl/v4l-dvb-
> cleanup/rev/7a762df57149 ? The patch should be committed to v4l-dvb in time
> f
Jarod Wilson writes:
> The bulk of breakage in lirc I've personally had to deal with has
> mostly come in the form of kernel interface changes, which would
> definitely be mitigated by not having to maintain the drivers
> out-of-tree any longer.
Certainly.
> Now, I'm all for "improving" things
Maxim Levitsky writes:
> There are many protocols,
Few of them really popular.
> There are many receivers, and all have different accuracy.
Receivers? Accuracy? What do you mean exactly?
> Most remotes aren't designed to be used with PC, thus user has to invent
> mapping between buttons and a
Trent Piepho writes:
> The signal recevied by the ir receiver contains glitches. Depending on the
> receiver there can be quite a few. It is also not trivial to turn the raw
> signal sent by the remote into a digital value, even if you know what to
> expect. It takes digital signal processing
Hi,
on 25 Nov 09 at 17:53, Krzysztof Halasa wrote:
> Jarod Wilson writes:
[...]
>> nimble. If we can come up with a shiny new way that raw IR can be
>> passed out through an input device, I'm pretty sure lirc userspace can
>> be adapted to handle that.
As Trent already pointed out, adding suppor
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-qv4l2 for the
following:
- v4l2-apps: add v4l2-apps/util/decode_tm6000 to .hgignore
- v4l2-apps: fix qv4l2 build
- v4l2-apps: fix the distclean makerules
- v4l2-apps: move qv4l2 to qv4l2-qt3
- v4l2-apps: add qv4l2 for Qt4
Th
On Tuesday 24 November 2009 18:15:02 Patch from Hans Verkuil wrote:
> The patch number 13462 was added via Mauro Carvalho Chehab
>
> to http://linuxtv.org/hg/v4l-dvb master development tree.
>
> Kernel patches in this development tree may be modified to be backward
> compatible with older kernel
l...@bartelmus.de (Christoph Bartelmus) writes:
> I'm not sure what two ways you are talking about. With the patches posted
> by Jarod, nothing has to be changed in userspace.
> Everything works, no code needs to be written and tested, everybody is
> happy.
The existing drivers use input laye
On Nov 25, 2009, at 11:53 AM, Krzysztof Halasa wrote:
> Jarod Wilson writes:
...
>> Now, I'm all for "improving" things and integrating better with the
>> input subsystem, but what I don't really want to do is break
>> compatibility with the existing setups on thousands (and thousands?)
>> of Myt
On Nov 25, 2009, at 12:40 PM, Krzysztof Halasa wrote:
> l...@bartelmus.de (Christoph Bartelmus) writes:
>
>> I'm not sure what two ways you are talking about. With the patches posted
>> by Jarod, nothing has to be changed in userspace.
>> Everything works, no code needs to be written and tested
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc for the
following:
- v4l2-subdev: remove unnecessary check
- cx18: remove bogus init call.
- cxusb: fix compile warning
- atbm8830: fix compile warning
- sh_mobile_ceu_camera: fix compile warning
- sh_mobile_ceu_camera:
Hi Mauro,
Dne Út 24. listopadu 2009 16:06:52 jste napsal(a):
> Hi Lukáš,
>
> Lukáš Karas wrote:
> > Hi Mauro,
> >
> > That isn't problem. Would it help you, if I send this patch as
> > attachment?
> >
> > Regards,
> > Lukas
> >
> > Dne Út 27. října 2009 13:06:22 jste napsal(a):
> >> Hi Kukáš,
>
Hi Dominic,
Am Mittwoch, den 25.11.2009, 08:31 -0800 schrieb Dominic Fernandes:
> Hi Hermann,
>
> Thanks for your reply. I'm a little lost in what to do next.
>
> How do I force the card to be recongised as card 169 (the compro videomate
> S350) instead of card 139?
unload the driver with "mo
On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson wrote:
> Took me a minute to figure out exactly what you were talking about. You're
> referring to the current in-kernel decoding done on an ad-hoc basis for
> assorted remotes bundled with capture devices, correct?
>
> Admittedly, unifying those and
Hans Verkuil wrote:
> Hi Mauro,
>
> Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the
> following:
>
> - spec: unexpand initial spaces when generating xml sources
> - spec: regenerated xml source files
Hans,
I'm not sure if t
On Nov 25, 2009, at 1:20 PM, Devin Heitmueller wrote:
> On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson wrote:
>> Took me a minute to figure out exactly what you were talking about. You're
>> referring to the current in-kernel decoding done on an ad-hoc basis for
>> assorted remotes bundled with
>
> Am Sonntag, den 15.11.2009, 17:15 +0200 schrieb rul...@meta.ua:
>> > Hi,
>> >
>> > Am Sonntag, den 15.11.2009, 14:42 +0200 schrieb rul...@meta.ua:
>> >> How to do that?:
>> >>
>> >> "You are forced to use saa7134-alsa dma sound"
>> >>
>> >
>> > a problem is that I can't tell for sure which anal
On Wednesday 25 November 2009 19:42:15 Mauro Carvalho Chehab wrote:
> Hans Verkuil wrote:
> > Hi Mauro,
> >
> > Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the
> > following:
> >
>
> > - spec: unexpand initial spaces when gen
Hans Verkuil wrote:
> Hi Mauro,
>
> Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-pms for the
> following:
>
> - pms: source code cleanup, use struct v4l2_device.
> - pms: convert from V4L1 to V4L2.
>
> It's time to get this merged. I always wanted to allow this driver to be used
Hans Verkuil wrote:
> On Wednesday 25 November 2009 19:42:15 Mauro Carvalho Chehab wrote:
>> Hans Verkuil wrote:
>>> Hi Mauro,
>>>
>>> Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the
>>> following:
>>>
>>> - spec: unexpand initi
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following:
- v4l: exclude .h.xml and .c.xml from the space-to-tab conversion
- spec: regenerate videodev2.h.xml
Thanks,
Hans
diffstat:
linux/Documentation/DocBook/v4l/videodev2.h.xml | 1096
Jarod Wilson writes:
> Ah, but the approach I'd take to converting to in-kernel decoding[*]
> would be this:
>
> 1) bring drivers in in their current state
>- users keep using lirc as they always have
>
> 2) add in-kernel decoding infra that feeds input layer
Well. I think the above is fine
This series of patches provide support for the TVP7002 decoder in DM365.
Support includes:
* Inclusion of the chip in v4l2 definitions
* Definition of TVP7002 specific data structures
* Kconfig and Makefile support
This series corrects many issued pointed out by Snehaprabha Narnakaje,
Muralidha
From: Santiago Nunez-Corrales
This patch provides required chip identification definitions
within v4l2.
Signed-off-by: Santiago Nunez-Corrales
---
include/media/v4l2-chip-ident.h |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-chip-ident.h b/
From: Santiago Nunez-Corrales
This patch provides the required definitions for the TVP7002 driver
in DM365.
Signed-off-by: Santiago Nunez-Corrales
---
drivers/media/video/tvp7002_reg.h | 150 +
include/media/tvp7002.h | 54 +
2 files
From: Santiago Nunez-Corrales
This patch provides the implementation of the TVP7002 decoder
driver for DM365. Implemented using the V4L2 DV presets API.
Removed shadow register values.
Signed-off-by: Santiago Nunez-Corrales
---
drivers/media/video/tvp7002.c | 1331 +
From: Santiago Nunez-Corrales
This patch provides menu configuration options for the TVP7002
decoder driver in DM365.
Signed-off-by: Santiago Nunez-Corrales
---
drivers/media/video/Kconfig | 41 +
drivers/media/video/Makefile |3 +++
2 files chang
On Wednesday 25 November 2009 20:39:08 santiago.nu...@ridgerun.com wrote:
> From: Santiago Nunez-Corrales
>
> This patch provides the required definitions for the TVP7002 driver
> in DM365.
>
> Signed-off-by: Santiago Nunez-Corrales
> ---
> drivers/media/video/tvp7002_reg.h | 150
> +
Jarod Wilson writes:
> Took me a minute to figure out exactly what you were talking about.
> You're referring to the current in-kernel decoding done on an ad-hoc
> basis for assorted remotes bundled with capture devices, correct?
Yes.
> Well, is there any reason most of those drivers with
> cur
Devin Heitmueller writes:
> The other key thing I don't think we have given much thought to is the
> fact that in many tuners, the hardware does RC decoding and just
> returns NEC/RC5/RC6 codes. And in many of those cases, the hardware
> has to be configured to know what format to receive. We p
Jarod Wilson writes:
> Well, we've got a number of IOCTLs already, could extend those.
> (Although its been suggested elsewhere that we replace the IOCTLs with
> sysfs knobs).
Not sure if sysfs would be fast enough.
> A simple sysfs attr that contains the name of the default config file
> for t
On Wednesday 25 November 2009 20:39:20 santiago.nu...@ridgerun.com wrote:
> From: Santiago Nunez-Corrales
>
> This patch provides the implementation of the TVP7002 decoder
> driver for DM365. Implemented using the V4L2 DV presets API.
> Removed shadow register values.
>
> Signed-off-by: Santiago
On Wed, Nov 25, 2009 at 03:28:54PM +0200, Maxim Levitsky wrote:
> On Tue, 2009-11-24 at 19:32 -0800, Trent Piepho wrote:
> > On Wed, 25 Nov 2009, Maxim Levitsky wrote:
> > > Its not the case.
> > > There are many protocols, I know that by experimenting with my universal
> > > remote. There are man
This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.
Results of the daily build of v4l-dvb:
date:Wed Nov 25 20:42:56 CET 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset: 13520:74ad936bcca2
gcc version: gcc (
On 11/25/09 19:20, Devin Heitmueller wrote:
On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson
wrote:
Took me a minute to figure out exactly what you were talking
about. You're referring to the current in-kernel decoding done on
an ad-hoc basis for assorted remotes bundled with capture devices,
corre
Hi,
Am Mittwoch, den 25.11.2009, 21:00 +0200 schrieb rul...@meta.ua:
> >
> > Am Sonntag, den 15.11.2009, 17:15 +0200 schrieb rul...@meta.ua:
> >> > Hi,
> >> >
> >> > Am Sonntag, den 15.11.2009, 14:42 +0200 schrieb rul...@meta.ua:
> >> >> How to do that?:
> >> >>
> >> >> "You are forced to use saa7
Hey,
I was wondering if this dish(1) would be working ok with a Hauppauge
HVR-4000, I read about some users not being able to use the built-in
Disecq switch, is that still true or can I safley invest in one?
The wiki doesn't say much about dishes an switches itzelf and as I
understand this d
Sean Young writes:
> Absolutely. There are a number of use cases when you want access to the
> space-pulse (i.e. IR) information.
I think nobody proposes otherwise (except for devices which can't pass
this info).
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following:
- dib8000: fix compile warning
- valj5jf8007s/t: fix compile warnings
- dvb-bt8xx: fix compile warning
- firedtv: require at least version 2.6.23.
- se401: fix 2.6.17 compile error.
- cx18: only build for ke
Hi Gerd,
on 25 Nov 09 at 22:58, Gerd Hoffmann wrote:
[...]
> (1) ir code (say rc5) -> keycode conversion looses information.
>
> I think this can easily be addressed by adding a IR event type to the
> input layer, which could look like this:
>
>input_event->type = EV_IR
>input_event->code
Well, I just can gin an information which is written on the chip of this
Aver Super 007 Analog(Only+FM) tuner:
NXP
SAA7131E103/G
CH2130
SF7227.1
TSG07142
Maybe this will help in developing driver for this device,
tvtime recieves signal much more worse then native AverMedia program for
this tuner
On Wed, 2009-11-25 at 23:30 +0100, Krzysztof Halasa wrote:
> Sean Young writes:
>
> > Absolutely. There are a number of use cases when you want access to the
> > space-pulse (i.e. IR) information.
>
> I think nobody proposes otherwise (except for devices which can't pass
> this info).
I think
On Wed, Nov 18, 2009 at 7:54 AM, Laurent Pinchart
wrote:
> Hi everybody,
>
> the V4L cleanup patches are now available from
>
> http://linuxtv.org/hg/~pinchartl/v4l-dvb-cleanup
>
> The tree will be rebased if needed (or rather dropped and recreated as hg
> doesn't provide a rebase operation), so p
(1) ir code (say rc5) -> keycode conversion looses information.
I think this can easily be addressed by adding a IR event type to the
input layer, which could look like this:
input_event->type = EV_IR
input_event->code = IR_RC5
input_event->value =
In case the 32bit value is too
Am Donnerstag, den 26.11.2009, 00:43 +0200 schrieb rul...@meta.ua:
> Well, I just can gin an information which is written on the chip of this
> Aver Super 007 Analog(Only+FM) tuner:
>
> NXP
> SAA7131E103/G
> CH2130
> SF7227.1
> TSG07142
Well, that is good to know and makes some other speculation
Hi Devin,
On Thursday 26 November 2009 00:06:40 Devin Heitmueller wrote:
> On Wed, Nov 18, 2009 at 7:54 AM, Laurent Pinchart
>
> wrote:
> > Hi everybody,
> >
> > the V4L cleanup patches are now available from
> >
> > http://linuxtv.org/hg/~pinchartl/v4l-dvb-cleanup
> >
> > The tree will be rebas
Your words:
"The huge delays in tvtime-scanner or xawtv scantv is a single experience
you report right now, nobody else".
So what -- maybe this is because nobody tells about it or just don't know
how to do that,
maybe because they don't have documentation and mailing lists in Russian
and Ukrainan
On Wed, Nov 25, 2009 at 7:02 PM, Laurent Pinchart
> Thank you very much for the report. Could you please try with the following
> patch applied on top of the v4l-dvb-cleanup tree ?
>
> diff -r 98e3929a1a2d linux/drivers/media/video/au0828/au0828-video.c
> --- a/linux/drivers/media/video/au0828/au08
Am Donnerstag, den 26.11.2009, 01:58 +0200 schrieb rul...@meta.ua:
> "You have a single card not working in the Ukraine currently, this might
> have political reasons"
>
> :))That is very funny
> And about tvtime scanner works very slow is true, I just say what I have
> did...
> What report do yo
On Wed, Nov 25, 2009 at 7:07 PM, Devin Heitmueller
> Trying it now
>
> Devin
Ok, that seems to have resolved the issue. Please make sure that
patch gets added to your PULL request.
Wish I had found that myself 90 minutes earlier... :-/
Thanks,
Devin
--
Devin J. Heitmueller - Kernel Lab
On Thursday 26 November 2009 01:17:51 Devin Heitmueller wrote:
> On Wed, Nov 25, 2009 at 7:07 PM, Devin Heitmueller
>
> > Trying it now
> >
> > Devin
>
> Ok, that seems to have resolved the issue. Please make sure that
> patch gets added to your PULL request.
I will. Thanks a lot for testin
Am Donnerstag, den 26.11.2009, 02:06 +0200 schrieb rul...@meta.ua:
> Your words:
>
> "The huge delays in tvtime-scanner or xawtv scantv is a single experience
> you report right now, nobody else".
>
> So what -- maybe this is because nobody tells about it or just don't know
> how to do that,
> m
Hi Magnus
> Do you have any mt9t112 platform data for the ecovec board? I'd like
> to try out this patch but I don't know which board specific parts that
> are missing!
Yes I have.
I attached it.
This platform patch is based on Guennadi's latest patches.
I also attached tw9910 platform patch.
P
On Wed, 2009-11-25 at 13:07 -0500, Jarod Wilson wrote:
> On Nov 25, 2009, at 12:40 PM, Krzysztof Halasa wrote:
>
> > l...@bartelmus.de (Christoph Bartelmus) writes:
> >
> >> I'm not sure what two ways you are talking about. With the patches posted
> >> by Jarod, nothing has to be changed in use
On Wed, 2009-11-25 at 13:20 -0500, Devin Heitmueller wrote:
> On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson wrote:
> > Took me a minute to figure out exactly what you were talking about. You're
> > referring to the current in-kernel decoding done on an ad-hoc basis for
> > assorted remotes bundl
Am Mittwoch, den 25.11.2009, 22:31 -0500 schrieb Andy Walls:
> On Wed, 2009-11-25 at 13:07 -0500, Jarod Wilson wrote:
> > On Nov 25, 2009, at 12:40 PM, Krzysztof Halasa wrote:
> >
> > > l...@bartelmus.de (Christoph Bartelmus) writes:
> > >
> > >> I'm not sure what two ways you are talking about.
On Wed, 2009-11-25 at 22:58 +0100, Gerd Hoffmann wrote:
> On 11/25/09 19:20, Devin Heitmueller wrote:
> > On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson
> > wrote:
> >> Took me a minute to figure out exactly what you were talking
> >> about. You're referring to the current in-kernel decoding done on
On Nov 25, 2009, at 2:27 PM, Krzysztof Halasa wrote:
> Jarod Wilson writes:
>
>> Ah, but the approach I'd take to converting to in-kernel decoding[*]
>> would be this:
>>
>> 1) bring drivers in in their current state
>> - users keep using lirc as they always have
>>
>> 2) add in-kernel decod
On Mon, Nov 23, 2009 at 09:51:31PM +0100, Krzysztof Halasa wrote:
> Dmitry Torokhov writes:
>
> > Curreently the "scan" codes in the input layer serve just to help users
> > to map whatever the device emits into a proper input event code so that
> > the rest of userspace would not have to care an
On Mon, Nov 23, 2009 at 11:37:53PM -0500, Jarod Wilson wrote:
> On 11/23/2009 12:37 PM, Dmitry Torokhov wrote:
>> On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote:
>>> Mauro Carvalho Chehab writes:
>>>
Event input has the advantage that the keystrokes will provide an unique
>>
On Wed, Nov 25, 2009 at 01:32:51AM +0200, Maxim Levitsky wrote:
> Folks, I really want to tell everyone that doing all the mapping from
> raw codes to keypresses in kernel is wrong.
Why is this wrong? Doing simple translation is easy and it does not
require having all the tables for all possible r
On Nov 25, 2009, at 10:31 PM, Andy Walls wrote:
> On Wed, 2009-11-25 at 13:07 -0500, Jarod Wilson wrote:
>> On Nov 25, 2009, at 12:40 PM, Krzysztof Halasa wrote:
>>
>>> l...@bartelmus.de (Christoph Bartelmus) writes:
>>>
I'm not sure what two ways you are talking about. With the patches pos
On Tue, Nov 24, 2009 at 07:32:42PM -0800, Trent Piepho wrote:
>
> One thing that could be done, unless it has changed much since I wrote it
> 10+ years ago, is to take the mark/space protocol the ir device uses and sent
> that data to lircd via the input layer. It would be less efficient, but
> w
On Mon, Nov 23, 2009 at 07:53:57PM -0500, Andy Walls wrote:
> On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote:
> > Czesc Krzysztof,
> >
> > on 23 Nov 09 at 15:14, Krzysztof Halasa wrote:
> > [...]
> > > I think we shouldn't at this time worry about IR transmitters.
> >
> > Sorry, but
On Wed, Nov 25, 2009 at 09:49:28PM +0100, Krzysztof Halasa wrote:
> Jarod Wilson writes:
>
> > Well, we've got a number of IOCTLs already, could extend those.
> > (Although its been suggested elsewhere that we replace the IOCTLs with
> > sysfs knobs).
>
> Not sure if sysfs would be fast enough.
Hi,
After fixing up a hang on the DViCO FusionHDTV DVB-T Dual Digital 4 (rev
1) recently via http://linuxtv.org/hg/v4l-dvb/rev/1c11cb54f24d everything
appeared to be ok, but I have now noticed certain channels in Australia
are showing corruption which manifest themselves as blockiness and
screechi
On Nov 26, 2009, at 12:31 AM, Dmitry Torokhov wrote:
> On Mon, Nov 23, 2009 at 11:37:53PM -0500, Jarod Wilson wrote:
>> On 11/23/2009 12:37 PM, Dmitry Torokhov wrote:
>>> On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote:
Mauro Carvalho Chehab writes:
> Event input h
Hi,
After fixing up a hang on the DViCO FusionHDTV DVB-T Dual Digital 4 (rev
1) recently via http://linuxtv.org/hg/v4l-dvb/rev/1c11cb54f24d everything
appeared to be ok, but I have now noticed certain channels in Australia
are showing corruption which manifest themselves as blockiness and
screechi
On Nov 26, 2009, at 12:49 AM, Dmitry Torokhov wrote:
> On Mon, Nov 23, 2009 at 07:53:57PM -0500, Andy Walls wrote:
>> On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote:
>>> Czesc Krzysztof,
>>>
>>> on 23 Nov 09 at 15:14, Krzysztof Halasa wrote:
>>> [...]
I think we shouldn't at th
Hey Morimoto-san,
On Thu, Nov 26, 2009 at 9:50 AM, Kuninori Morimoto
wrote:
>> Do you have any mt9t112 platform data for the ecovec board? I'd like
>> to try out this patch but I don't know which board specific parts that
>> are missing!
>
> Yes I have.
> I attached it.
> This platform patch is b
On Wednesday 25 November 2009 23:32:31 Hans Verkuil wrote:
> Hi Mauro,
>
> Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the
> following:
>
> - dib8000: fix compile warning
> - valj5jf8007s/t: fix compile warnings
> - dvb-bt8xx: fix compile warning
> - firedtv: require at leas
Hi Krzysztof,
I did a quick review and found just two small things. If you fix those,
then you can add a
Reviewed-by: Hans Verkuil
line to your patch.
Thanks,
Hans
On Tuesday 24 November 2009 22:12:36 Krzysztof Helt wrote:
> From: Krzysztof Helt
>
> This is recreated driver for the
90 matches
Mail list logo