Hi,
This patch fix compilation warning for cxusb mygica d689 and clean up
unused code.
Regards,
David
Signed-off-by: David T. L. Wong davidtlw...@gmail.com
diff --git a/linux/drivers/media/dvb/dvb-usb/cxusb.c b/linux/drivers/media/dvb/dvb-usb/cxusb.c
---
Hi,
This patch improves ATBM8830 reception by using per card AGC
configuration rather than register default.
Regards,
David
Signed-off-by: David T. L. Wong davidtlw...@gmail.com
diff --git a/linux/drivers/media/dvb/dvb-usb/cxusb.c b/linux/drivers/media/dvb/dvb-usb/cxusb.c
---
On Sat, Nov 28, 2009 at 1:35 AM, Andy Walls awa...@radix.net wrote:
On Fri, 2009-11-27 at 16:11 -0500, Andy Walls wrote:
Steve and Hans,
Any ideas?
I know on the list I had bantered around a configure, enable, set, get
etc v4l2_subdev ops for gpio, but I can't remember the details nor the
On Sat, 2009-11-28 at 12:20 +0100, Krzysztof Halasa wrote:
Maxim Levitsky maximlevit...@gmail.com writes:
If we add in-kernel decoding, we still will end up with two different
decoding, one in kernel and one in lirc.
And that's good. Especially for a popular and simple protocol such as
Maxim Levitsky maximlevit...@gmail.com writes:
And that's good. Especially for a popular and simple protocol such as
RC5.
Actually, it's not about adding the decoder. It's about fixing it.
I can fix it.
This is nonsense.
You forgot to say why do you think so.
--
Krzysztof Halasa
--
To
On Sat, 2009-11-28 at 16:25 +0100, Krzysztof Halasa wrote:
Maxim Levitsky maximlevit...@gmail.com writes:
And that's good. Especially for a popular and simple protocol such as
RC5.
Actually, it's not about adding the decoder. It's about fixing it.
I can fix it.
This is nonsense.
Maxim Levitsky maximlevit...@gmail.com writes:
Generic decoder that lirc has is actually much better and more tolerant
that protocol specific decoders that you propose,
Actually, it is not the case. Why do you think it's better (let alone
much better)? Have you at least seen my RC5 decoder?
On Sat, 2009-11-28 at 16:44 +0100, Krzysztof Halasa wrote:
Maxim Levitsky maximlevit...@gmail.com writes:
Generic decoder that lirc has is actually much better and more tolerant
that protocol specific decoders that you propose,
Actually, it is not the case. Why do you think it's better
On Sat, Nov 28, 2009 at 10:35 AM, Maxim Levitsky
maximlevit...@gmail.com wrote:
On Sat, 2009-11-28 at 16:25 +0100, Krzysztof Halasa wrote:
Maxim Levitsky maximlevit...@gmail.com writes:
And that's good. Especially for a popular and simple protocol such as
RC5.
Actually, it's not about
Hi Krzysztof and Maxim,
on 28 Nov 09 at 16:44, Krzysztof Halasa wrote:
Maxim Levitsky maximlevit...@gmail.com writes:
Generic decoder that lirc has is actually much better and more tolerant
that protocol specific decoders that you propose,
Actually, it is not the case. Why do you think it's
On Sat, Nov 28, 2009 at 11:47 AM, Christoph Bartelmus l...@bartelmus.de wrote:
@Maxim: I think Mauro is right. We need to find an approach that makes
everybody happy. We should take the time now to discuss all the
possibilities and choose the best solution. LIRC has lived so long outside
the
l...@bartelmus.de (Christoph Bartelmus) writes:
Nobody here doubts that you can implement a working RC-5 decoder. It's
really easy. I'll give you an example why Maxim thinks that the generic
LIRC approach has advantages:
But surely not when compared to an in-kernel decoder _and_ the one
Jon Smirl jonsm...@gmail.com writes:
There are two very basic things that we need to reach consensus on first.
1) Unification with mouse/keyboard in evdev - put IR on equal footing.
2) Specific tools (xmodmap, setkeycodes, etc or the LIRC ones) or
generic tools (ls, mkdir, echo) for
On Sat, Nov 28, 2009 at 12:35 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
Jon Smirl jonsm...@gmail.com writes:
There are two very basic things that we need to reach consensus on first.
1) Unification with mouse/keyboard in evdev - put IR on equal footing.
2) Specific tools (xmodmap,
Jon Smirl jonsm...@gmail.com writes:
1. Merging the lirc drivers. The only stable thing needed is lirc
interface.
Doing that locks in a user space API that needs to be supported
forever. We need to think this API through before locking it in.
Sure, that's why I wrote about the need for it
On Sat, 28 Nov 2009 08:13:05 +0100
Németh Márton nm...@freemail.hu wrote:
what do you think about this patch?
Hi Márton,
There are many other drivers where the usb_control_msg() errors are not
tested nor propagated to higher levels. Generally, this does not matter:
the errors are signalled at
Jon Smirl wrote:
There are two very basic things that we need to reach consensus on first.
1) Unification with mouse/keyboard in evdev - put IR on equal footing.
2) Specific tools (xmodmap, setkeycodes, etc or the LIRC ones) or
generic tools (ls, mkdir, echo) for configuration
About 2: If
On Sat, 2009-11-28 at 11:45 -0500, Jon Smirl wrote:
On Sat, Nov 28, 2009 at 10:35 AM, Maxim Levitsky
maximlevit...@gmail.com wrote:
On Sat, 2009-11-28 at 16:25 +0100, Krzysztof Halasa wrote:
Maxim Levitsky maximlevit...@gmail.com writes:
And that's good. Especially for a popular and
On Sat, Nov 28, 2009 at 1:45 PM, Maxim Levitsky maximlevit...@gmail.com wrote:
On Sat, 2009-11-28 at 11:45 -0500, Jon Smirl wrote:
What are other examples of user space IR drivers?
many libusb based drivers?
If these drivers are for specific USB devices it is straight forward
to turn them
On Sat, 28 Nov 2009 08:14:57 +0100
Németh Márton nm...@freemail.hu wrote:
what do you think about the latest version of this patchset?
Hello Márton,
I wonder why you did not include the input functions directly in the
file gspca.c instead of adding new files and changing the Makefile.
Below
On Sat, Nov 28, 2009 at 1:17 PM, Stefan Richter
stef...@s5r6.in-berlin.de wrote:
Jon Smirl wrote:
There are two very basic things that we need to reach consensus on first.
1) Unification with mouse/keyboard in evdev - put IR on equal footing.
2) Specific tools (xmodmap, setkeycodes, etc or
On Tue, 10 Nov 2009, Ian Molton wrote:
Well if they are only masked they shouldnt stop being asserted. But we
should unmask them again.
Im not really sure we should mask them anyway, with the card possibly
being gone... Will need to look into it further.
Hi Ingo
What's the status of this
On Sat, 2009-11-28 at 13:56 -0500, Jon Smirl wrote:
On Sat, Nov 28, 2009 at 1:45 PM, Maxim Levitsky maximlevit...@gmail.com
wrote:
On Sat, 2009-11-28 at 11:45 -0500, Jon Smirl wrote:
What are other examples of user space IR drivers?
many libusb based drivers?
If these drivers are
Jon Smirl wrote:
If these drivers are for specific USB devices it is straight forward
to turn them into kernel based drivers. If we are going for plug and
play this needs to happen. All USB device drivers can be implemented
in user space, but that doesn't mean you want to do that. Putting
On Sat, Nov 28, 2009 at 2:30 PM, Stefan Richter
stef...@s5r6.in-berlin.de wrote:
Jon Smirl wrote:
If these drivers are for specific USB devices it is straight forward
to turn them into kernel based drivers. If we are going for plug and
play this needs to happen. All USB device drivers can be
Jon Smirl wrote:
On Sat, Nov 28, 2009 at 1:17 PM, Stefan Richter
stef...@s5r6.in-berlin.de wrote:
Jon Smirl wrote:
There are two very basic things that we need to reach consensus on first.
1) Unification with mouse/keyboard in evdev - put IR on equal footing.
2) Specific tools (xmodmap,
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:Sat Nov 28 19:00:06 CET 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset: 13536:9c38704cfd56
gcc version: gcc
Jon Smirl wrote:
On Sat, Nov 28, 2009 at 2:30 PM, Stefan Richter
stef...@s5r6.in-berlin.de wrote:
Jon Smirl wrote:
If these drivers are for specific USB devices it is straight forward
to turn them into kernel based drivers. If we are going for plug and
play this needs to happen. All USB
Jon Smirl jonsm...@gmail.com writes:
EVIOCSKEYCODE is lacking, first parameter is an INT. Some decoded IR
codes are over 32b. Christoph posted an example that needs 128b.
This only means that the existing interface is limited.
This
is a problem with ioctls, they change size depending on
On Sat, Nov 28, 2009 at 2:45 PM, Stefan Richter
stef...@s5r6.in-berlin.de wrote:
Jon Smirl wrote:
Also, how do you create the devices for each remote? You would need to
create these devices before being able to do EVIOCSKEYCODE to them.
The input subsystem creates devices on behalf of input
On Sat, Nov 28, 2009 at 2:55 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
Jon Smirl jonsm...@gmail.com writes:
EVIOCSKEYCODE is lacking, first parameter is an INT. Some decoded IR
codes are over 32b. Christoph posted an example that needs 128b.
This only means that the existing interface is
Jon Smirl jonsm...@gmail.com writes:
We have one IR receiver device and multiple remotes. How does the
input system know how many devices to create corresponding to how many
remotes you have? There is no current mechanism to do that. You need
an input device for each remote so that you can do
Jon Smirl jonsm...@gmail.com writes:
Endianess comes into play when send/receiving multibyte integers on
platforms with different endianess.
It's the case when you're sending this data to a machine with
a different endianness. For example, in a network or to another CPU in
e.g. add-on card.
Jon Smirl wrote:
On Sat, Nov 28, 2009 at 2:45 PM, Stefan Richter
stef...@s5r6.in-berlin.de wrote:
Jon Smirl wrote:
Also, how do you create the devices for each remote? You would need to
create these devices before being able to do EVIOCSKEYCODE to them.
The input subsystem creates devices on
On Sat, 28 Nov 2009, Hans Verkuil wrote:
On Friday 27 November 2009 22:40:01 Stefan Lippers-Hollmann wrote:
Hi
On Friday 27 November 2009, Mauro Carvalho Chehab wrote:
Hi Linus,
Please pull from:
Stefan Richter wrote:
Jon Smirl wrote:
We have one IR receiver device and multiple remotes. How does the
input system know how many devices to create corresponding to how many
remotes you have?
If several remotes are to be used on the same receiver, then they
necessarily need to generate
On Sat, Nov 28, 2009 at 3:29 PM, Stefan Richter
stef...@s5r6.in-berlin.de wrote:
Jon Smirl wrote:
On Sat, Nov 28, 2009 at 2:45 PM, Stefan Richter
stef...@s5r6.in-berlin.de wrote:
Jon Smirl wrote:
Also, how do you create the devices for each remote? You would need to
create these devices
Hello,
my new card will not tune, it has a problem with the firmware I am offering.
Does not seem to fit. TV-out with this card works fine.
Here's my log:
Nov 28 15:35:00 vdr kernel: saa7146: register extension 'dvb'.
Nov 28 15:35:00 vdr kernel: dvb :00:0d.0: enabling device (0004 - 0006)
Add automatic probing of ports 0x284 and 0x384 to radio-sf16fmi if no card is
found using PnP.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
--- linux-source-2.6.31/drivers/media/radio/Kconfig.1 2009-11-28
21:40:32.0 +0100
+++ linux-source-2.6.31/drivers/media/radio/Kconfig
On Sat, Nov 28, 2009 at 4:46 PM, Stefan Richter
stef...@s5r6.in-berlin.de wrote:
Jon Smirl wrote:
On Sat, Nov 28, 2009 at 3:29 PM, Stefan Richter
stef...@s5r6.in-berlin.de wrote:
Jon Smirl wrote:
We have one IR receiver device and multiple remotes. How does the
input system know how many
I'm looking at a Sony multi-function remote right now. It has five
devices and forty keys. Each of the five devices can transmit 0-9,
power, volume, etc. It transmits 5*40 = 200 unique scancodes.
I want the five devices to correspond to five apps. What's the plan
for splitting those 200 scancodes
Hello everyone.
I am trying to build v4l-dvb device drivers according to instruction
on linuxTV wiki
http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers
but it fails when compiling dvb_frontend.c
This is what I get:
Jon,
On Sat, 2009-11-28 at 12:37 -0500, Jon Smirl wrote:
On Sat, Nov 28, 2009 at 12:35 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
Jon Smirl jonsm...@gmail.com writes:
There are two very basic things that we need to reach consensus on first.
1) Unification with mouse/keyboard in evdev -
Hi Hermann,
I'm getting closer!!!
I'm using ubuntu 9.10, unloading saa7134 alsa wasn't working for me so I put it
into the blacklist which prevented it from loading and then I was able to do
the modprobe -vr saa7134-alsa saa7134-dvb and modprobe -v saa7134 card=16.
And now the card
On Sat, Nov 28, 2009 at 4:39 AM, Antonio Ospite
osp...@studenti.unina.it wrote:
On Tue, 17 Nov 2009 23:04:20 +0100
Antonio Ospite osp...@studenti.unina.it wrote:
Hi,
this series removes the init() callback from pxa_camera_platform_data, and
fixes its users to do initialization statically at
On Sat, Nov 28, 2009 at 4:31 AM, Antonio Ospite
osp...@studenti.unina.it wrote:
pxa_camera init() is ambiguous, it's better to configure PXA CIF pins
statically in machine init function.
Signed-off-by: Antonio Ospite osp...@studenti.unina.it
I'll grab this and get it exposed to next -rc
On Sat, 28 Nov 2009 02:27:59 am Jon Smirl wrote:
On Fri, Nov 27, 2009 at 2:45 AM, Christoph Bartelmus
christ...@bartelmus.de wrote:
Hi Mauro,
on 26 Nov 09 at 14:25, Mauro Carvalho Chehab wrote:
Christoph Bartelmus wrote:
[...]
But I'm still a bit hesitant about the in-kernel
On Sat, 2009-11-28 at 12:37 -0500, Jon Smirl wrote:
On Sat, Nov 28, 2009 at 12:35 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
Jon Smirl jonsm...@gmail.com writes:
There are two very basic things that we need to reach consensus on first.
1) Unification with mouse/keyboard in evdev - put
On Sat, Nov 28, 2009 at 11:32:01PM -0500, Andy Walls wrote:
On Sat, 2009-11-28 at 12:37 -0500, Jon Smirl wrote:
On Sat, Nov 28, 2009 at 12:35 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
Jon Smirl jonsm...@gmail.com writes:
There are two very basic things that we need to reach consensus
On Sun, Nov 29, 2009 at 01:17:03PM +1030, Mike Lampard wrote:
On Sat, 28 Nov 2009 02:27:59 am Jon Smirl wrote:
On Fri, Nov 27, 2009 at 2:45 AM, Christoph Bartelmus
christ...@bartelmus.de wrote:
Hi Mauro,
on 26 Nov 09 at 14:25, Mauro Carvalho Chehab wrote:
Christoph Bartelmus
On Sat, Nov 28, 2009 at 06:26:55PM -0500, Andy Walls wrote:
Jon,
On Sat, 2009-11-28 at 12:37 -0500, Jon Smirl wrote:
On Sat, Nov 28, 2009 at 12:35 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
Jon Smirl jonsm...@gmail.com writes:
There are two very basic things that we need to reach
On Sat, Nov 28, 2009 at 05:18:34PM -0500, Jon Smirl wrote:
I'm looking at a Sony multi-function remote right now. It has five
devices and forty keys. Each of the five devices can transmit 0-9,
power, volume, etc. It transmits 5*40 = 200 unique scancodes.
I want the five devices to correspond
On Sun, 29 Nov 2009 03:25:49 pm Dmitry Torokhov wrote:
On Sun, Nov 29, 2009 at 01:17:03PM +1030, Mike Lampard wrote:
On Sat, 28 Nov 2009 02:27:59 am Jon Smirl wrote:
On Fri, Nov 27, 2009 at 2:45 AM, Christoph Bartelmus
christ...@bartelmus.de wrote:
Hi Mauro,
on 26 Nov 09 at
On Sun, Nov 29, 2009 at 04:01:53PM +1030, Mike Lampard wrote:
On Sun, 29 Nov 2009 03:25:49 pm Dmitry Torokhov wrote:
On Sun, Nov 29, 2009 at 01:17:03PM +1030, Mike Lampard wrote:
On Sat, 28 Nov 2009 02:27:59 am Jon Smirl wrote:
On Fri, Nov 27, 2009 at 2:45 AM, Christoph Bartelmus
On Thu, Nov 26, 2009 at 10:34:55PM -0500, Jon Smirl wrote:
On Thu, Nov 26, 2009 at 10:12 PM, Jarod Wilson ja...@wilsonet.com wrote:
This part... Not so wild about. The common thought I'm seeing from people is
that we should be using setkeycode to load keymaps. I mean, sure, I suppose
this
On Thu, Nov 26, 2009 at 10:58:59PM -0500, Jon Smirl wrote:
Code is only lightly tested. Encoders and decoders have not been
written for all protocols. Repeat is not handled for any protocol. I'm
looking for help. There are 15 more existing LIRC drivers.
And there's the hangup for me.
56 matches
Mail list logo
