From: Márton Németh nm...@freemail.hu
Eliminate redundant code by reorganizing the loop.
Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r 064a82aa2daa linux/drivers/media/video/gspca/gspca.c
--- a/linux/drivers/media/video/gspca/gspca.c Thu Nov 26 19:36:40 2009 +0100
+++
From: Márton Németh nm...@freemail.hu
Calling gspca_set_alt0() in gspca_dev_probe() is not needed as gspca_set_alt0()
will do nothing because gspca_dev-alt is always zero at that time.
Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r 064a82aa2daa linux/drivers/media/video/gspca/gspca.c
On Sun, 29 Nov 2009 11:24:31 +0100
Németh Márton nm...@freemail.hu wrote:
From: Márton Németh nm...@freemail.hu
Eliminate redundant code by reorganizing the loop.
Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r 064a82aa2daa linux/drivers/media/video/gspca/gspca.c
---
Hello list
I try to build latest s2-liplianin drivers but make shows severals
warnings and module not load after build driver:
WARNING: ir_input_keydown [s2-liplianin/v4l/mantis.ko] undefined!
WARNING: ir_codes_mantis_vp1041_table [s2-liplianin/v4l/mantis.ko] undefined!
WARNING: ir_input_nokey
Hi Jon,
on 27 Nov 09 at 12:49, Jon Smirl wrote:
[...]
Christoph, take what you know from all of the years of working on LIRC
and design the perfect in-kernel system. This is the big chance to
redesign IR support and get rid of any past mistakes. Incorporate any
useful chunks of code and
Hi Mauro,
on 28 Nov 09 at 09:21, Mauro Carvalho Chehab wrote:
Hi Christoph,
Christoph Bartelmus wrote:
Maybe we decide to take the existing LIRC system as is and not
integrate it into the input subsystem. But I think there is a window
here to update the LIRC design to use the latest kernel
Hi Krzysztof,
on 28 Nov 09 at 18:21, Krzysztof Halasa wrote:
[...]
This remote uses RC-5. But some of the developers must have thought that
it may be a smart idea to use 14 bits instead the standard 13 bits for
this remote. In LIRC you won't care, because this is configurable and
irrecord
Hi Stefan,
on 28 Nov 09 at 21:29, Stefan Richter 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 before being able to do
On Sun, 29 Nov 2009 12:19:46 +0100
Németh Márton nm...@freemail.hu wrote:
Is there any subdriver where the isoc_nego() is implemented? I
couldn't find one. What would be the task of the isoc_nego()
function? Should it set the interface by calling usb_set_interface()
as the get_ep() does?
Jean-Francois Moine wrote:
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
Hi All,
I am trying to configure a Winfast PxDVR3200 H on Ubuntu
9.10 (Karmic). Although the card seems to be detected, there is no
signal when I try to scan for channels either using scan or a variety
of software interfaces (me tv, kaffeine, myth tv). All give a signal
strength of 0. Any help at
BTW, circa 1995 my serial mouse Just Worked in Linux. Sometime around
Correct X11 just talked to the serial ports. In fact that is still the
way to configure it if you want any sanity in life.
and serial connected IRs. It's also too convenient to access USB IR
hardware from existing
On Thu, 2009-11-26 at 17:43 +0100, Matthias Fechner wrote:
Hi Andy,
Andy Walls wrote:
I will inspect and test these with my HVR-1850 (CX23888) loaner board
this weekend (hopefully).
if you want me to test something on the Tevii S470 card, please let me know.
MAtthias,
Not right
Hello,
I did a smatch static checker run and found a double unlock in
bttv-driver.c.
drivers/media/video/bt8xx/bttv-driver.c +3203 bttv_poll() error: double unlock
'fh-cap.vb_lock'
I would fix it myself, but I don't know if the poll_wait() is supposed
to be protected by
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
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 to five apps. What's the plan
for
Jon Smirl wrote:
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
Hi,
On 11/29/2009 01:15 PM, Jean-Francois Moine wrote:
On Sun, 29 Nov 2009 12:19:46 +0100
Németh Mártonnm...@freemail.hu wrote:
Is there any subdriver where the isoc_nego() is implemented? I
couldn't find one. What would be the task of the isoc_nego()
function? Should it set the interface by
This was found with a static checker and has not been tested, but it seems
pretty clear that the mutex_lock() was supposed to be mutex_unlock()
This is a 2.6.32 candidate.
On Thu, Nov 26, 2009 at 08:34:23PM -0500, Jon Smirl wrote:
Changes to core input subsystem to allow send and receive of IR messages.
Encode and decode state machines are provided for common IR porotocols such
as Sony, JVC, NEC, Philips, etc.
Received IR messages generate event in the input
+static ssize_t ir_raw_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct input_dev *input_dev = to_input_dev(dev);
+ unsigned int i, count = 0;
+
+ for (i = input_dev-ir-raw.tail; i != input_dev-ir-raw.head; ) {
+
+
On Sun, 2009-11-29 at 12:40 +, Alan Cox wrote:
BTW, circa 1995 my serial mouse Just Worked in Linux. Sometime around
Correct X11 just talked to the serial ports. In fact that is still the
way to configure it if you want any sanity in life.
and serial connected IRs. It's also too
On Sun, Nov 29, 2009 at 12:17 PM, Greg KH g...@kroah.com wrote:
+static ssize_t ir_raw_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct input_dev *input_dev = to_input_dev(dev);
+ unsigned int i, count = 0;
+
+ for (i
On Sun, Nov 29, 2009 at 9:28 AM, Maxim Levitsky maximlevit...@gmail.com wrote:
This has zero advantages besides good developer feeling that My system
has one less daemon...
Surely it's clear that having an unnecessary daemon is introducing
another point of failure? Reducing complexity is not
If decoding can *only* be sanely handled in user-space, that's one
thing. If it can be handled in kernel, then that would be better.
Why ?
I can compute fast fourier transforms in the kernel but that doesn't make
it better than doing it in user space. I can write web servers in the
kernel and
On Sun, Nov 29, 2009 at 10:13 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
If decoding can *only* be sanely handled in user-space, that's one
thing. If it can be handled in kernel, then that would be better.
Why ?
I can compute fast fourier transforms in the kernel but that doesn't make
it
Half of the drivers are in user space and there are two different
classes of kernel driver - LIRC and V4L.
A lot of the hardware doesn't identify itself.
There are two types of IR data in use - pulse timing and decoded protocol.
IR is an input device. We have a nice evdev input subsystem
Jon is asking for an architecture discussion, y'know, with use cases.
Maxim seems to be saying it's obvious that what we have today works
fine. Except it doesn't appear that we have a consensus that
everything is fine, nor an obvious winner for how to reduce the
complexity here and keep the
On Sun, Nov 29, 2009 at 12:37:36PM -0500, Jon Smirl wrote:
On Sun, Nov 29, 2009 at 12:14 PM, Greg KH g...@kroah.com wrote:
On Thu, Nov 26, 2009 at 08:34:23PM -0500, Jon Smirl wrote:
Changes to core input subsystem to allow send and receive of IR messages.
Encode and decode state machines
On Sun, Nov 29, 2009 at 12:41:22PM -0500, Jon Smirl wrote:
On Sun, Nov 29, 2009 at 12:17 PM, Greg KH g...@kroah.com wrote:
+static ssize_t ir_raw_show(struct device *dev,
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct device_attribute *attr, char *buf)
+{
+ ? ? struct input_dev *input_dev =
On Sun, Nov 29, 2009 at 2:04 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Jon is asking for an architecture discussion, y'know, with use cases.
Maxim seems to be saying it's obvious that what we have today works
fine. Except it doesn't appear that we have a consensus that
everything is fine,
So we're just back to the status quo of last year which is to do
nothing except some minor clean up.
Which in itself is vastly preferable to some grandiose scheme that turns
out to be wrong.
And no it's not a back to the status quo, it's a request to discuss the
actual problems and options not
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:Sun Nov 29 19:00:05 CET 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset: 13538:e0cd9a337600
gcc version: gcc
Hi,
on 29 Nov 09 at 14:16, Jon Smirl wrote:
On Sun, Nov 29, 2009 at 2:04 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Jon is asking for an architecture discussion, y'know, with use cases.
[...]
So we're just back to the status quo of last year which is to do
nothing except some minor clean
Signed-off-by: Thiago Farina tfrans...@gmail.com
---
drivers/media/video/cpia2/cpia2_v4l.c | 27 +++
1 files changed, 11 insertions(+), 16 deletions(-)
diff --git a/drivers/media/video/cpia2/cpia2_v4l.c
b/drivers/media/video/cpia2/cpia2_v4l.c
index 0b4a8f3..6c5fcd8
Hi,
since I've been having problems with not seeing my IR remote in recent
kernelsx any more (starting at least with 2.6.30) I tried the current
version of the v4l-dvb tree (revision 13538) and 2.6.32-rc7 on my amd64
with a Hauppauge HVR1300.
With that version I get a kernel bug upon module
1. Do we agree that a lirc (-style) kernel-user interface is needed at
least?
2. Is there any problem with lirc kernel-user interface?
If the answer for #1 is yes and for #2 is no then perhaps we merge
the Jarod's lirc patches (at least the core) so at least the
non-controversial part is
On Sun, Nov 29, 2009 at 3:27 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
1. Do we agree that a lirc (-style) kernel-user interface is needed at
least?
2. Is there any problem with lirc kernel-user interface?
Can you consider sending the raw IR data as a new evdev message type
instead of
On Nov 29, 2009, at 12:44 PM, Jon Smirl jonsm...@gmail.com wrote:
On Sun, Nov 29, 2009 at 3:27 PM, Krzysztof Halasa k...@pm.waw.pl
wrote:
1. Do we agree that a lirc (-style) kernel-user interface is needed
at
least?
2. Is there any problem with lirc kernel-user interface?
Can you
On Nov 29, 2009, at 12:27 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
1. Do we agree that a lirc (-style) kernel-user interface is needed at
least?
2. Is there any problem with lirc kernel-user interface?
If the answer for #1 is yes and for #2 is no then perhaps we merge
the Jarod's lirc
Mauro,
Please pull from http://linuxtv.org/hg/~pinchartl/v4l-dvb-cleanup/
for the following 9 changesets:
v4l: Add video_device_node_name function
v4l: Use the new video_device_node_name function
v4l: Remove video_device::num usage
Mike Lampard wrote:
an example I have a VDR instance running in the background on my desktop
machine outputting to a TV in another room via a pci mpeg decoder - I
certainly don't want the VDR remote control interacting with my X11 desktop
in
any way unless I go out of my way to set it up
On Nov 29, 2009, at 1:47 PM, Jon Smirl jonsm...@gmail.com wrote:
On Sun, Nov 29, 2009 at 4:29 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
On Nov 29, 2009, at 12:44 PM, Jon Smirl jonsm...@gmail.com wrote:
On Sun, Nov 29, 2009 at 3:27 PM, Krzysztof Halasa k...@pm.waw.pl
wrote:
1.
On Sun, 2009-11-29 at 09:49 -0800, Ray Lee wrote:
On Sun, Nov 29, 2009 at 9:28 AM, Maxim Levitsky maximlevit...@gmail.com
wrote:
This has zero advantages besides good developer feeling that My system
has one less daemon...
Surely it's clear that having an unnecessary daemon is
Am Samstag, den 28.11.2009, 11:55 +0100 schrieb tomloh...@gmail.com:
hermann pitton a écrit :
Hi Tom,
Am Mittwoch, den 18.11.2009, 14:06 +0100 schrieb tomloh...@gmail.com:
Hello list,
looking from saa7134.h, this board 5168:0307 is not included
This cars is on some asus
Hi Dominic,
Am Samstag, den 28.11.2009, 17:30 -0800 schrieb Dominic Fernandes:
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
On Sun, Nov 29, 2009 at 3:35 PM, Andy Walls awa...@radix.net wrote:
If decoding can *only* be sanely handled in user-space, that's one
thing. If it can be handled in kernel, then that would be better.
Why does the address space in which decoding is performed make the
decoding process better
On Nov 29, 2009, at 4:31 PM, Dmitry Torokhov wrote:
On Nov 29, 2009, at 12:27 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
1. Do we agree that a lirc (-style) kernel-user interface is needed at
least?
2. Is there any problem with lirc kernel-user interface?
If the answer for #1 is yes
On Nov 27, 2009, at 12:06 AM, Jon Smirl wrote:
On Thu, Nov 26, 2009 at 11:33 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
In the code I posted there is one evdev device for each configured
remote. Mapped single keycodes are presented on these devices for each
IR burst. There is no
hermann pitton a écrit :
Hi Thomas,
Hi Hermann,
thanks for informations ...
This card is not mine so physically inspect it is not possible and the
owner is at 700 kms from me...
However, it seems there is only one hybrid tuner. The card is referenced as
AR307 rev N (seen on
50 matches
Mail list logo
