On Thu, Nov 26, 2009 at 09:28:51PM -0500, Jarod Wilson wrote:
> On 11/26/2009 06:23 PM, Dmitry Torokhov wrote:
>> On Thu, Nov 26, 2009 at 01:16:01AM -0500, Jarod Wilson wrote:
>>> On Nov 26, 2009, at 12:31 AM, Dmitry Torokhov wrote:
>>>
>>>> On Mon, Nov 23,
On Thu, Nov 26, 2009 at 10:08:29PM -0500, Jon Smirl wrote:
> On Thu, Nov 26, 2009 at 9:28 PM, Jarod Wilson wrote:
> >> No, at present we expect 1:1 button->event mapping leaving macro
> >> expansion (i.e. KEY_PROG1 -> "do some multi-step sequence" to
> >> userspace).
> >
> > Hm. So ctrl-x, alt-ta
On Fri, Nov 27, 2009 at 02:21:13PM -0500, Jon Smirl wrote:
> On Fri, Nov 27, 2009 at 2:03 PM, Ferenc Wagner wrote:
> > Admittedly, I don't know why /dev/mouse is evil, maybe I'd understand if
>
> /dev/mouse is evil because it is possible to read partial mouse
> messages. evdev fixes things so tha
On Sat, Nov 28, 2009 at 12:39:18AM -0200, Mauro Carvalho Chehab wrote:
> Em Thu, 26 Nov 2009 17:06:03 -0200
> Mauro Carvalho Chehab escreveu:
>
> > Krzysztof Halasa wrote:
> > > Mauro Carvalho Chehab writes:
> > >
> > >> Technically, it is not hard to port this solution to the other
> > >> driv
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 wrote:
> > > Jon Smirl writes:
> > >
> > >> There are two very basic things that we need to reach consensus on first.
> > >>
> >
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
> >
> > wrote:
> > > Hi Mauro,
> > >
> > > on 26 Nov 09 at 14:25, Mauro Carvalho Chehab wrote:
> > >> Christoph Bartelmus wrote
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 wrote:
> > > Jon Smirl writes:
> > >
> > >> There are two very basic things that we need to reach consensus on first.
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 corres
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
On Thu, Nov 26, 2009 at 10:34:55PM -0500, Jon Smirl wrote:
> On Thu, Nov 26, 2009 at 10:12 PM, Jarod Wilson 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 could be abst
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 ha
On Nov 29, 2009, at 12:44 PM, Jon Smirl wrote:
On Sun, Nov 29, 2009 at 3:27 PM, Krzysztof Halasa
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
On Nov 29, 2009, at 12:27 PM, Krzysztof Halasa 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 patches (at le
On Nov 29, 2009, at 1:47 PM, Jon Smirl wrote:
On Sun, Nov 29, 2009 at 4:29 PM, Dmitry Torokhov
wrote:
On Nov 29, 2009, at 12:44 PM, Jon Smirl wrote:
On Sun, Nov 29, 2009 at 3:27 PM, Krzysztof Halasa
wrote:
1. Do we agree that a lirc (-style) kernel-user interface is
needed at
On Mon, Nov 30, 2009 at 03:33:52PM -0200, Mauro Carvalho Chehab wrote:
> kevin granade wrote:
> > On Mon, Nov 30, 2009 at 7:24 AM, Mauro Carvalho Chehab
> > wrote:
> >
> >> After the boot, a device can open the raw API, disabling any in-kernel
> >> decoding/handling and handle IR directly. Altern
On Mon, Nov 30, 2009 at 04:27:56PM -0200, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> > On Mon, Nov 30, 2009 at 03:33:52PM -0200, Mauro Carvalho Chehab wrote:
> >> kevin granade wrote:
> >>> On Mon, Nov 30, 2009 at 7:24 AM, Mauro Carvalho Chehab
> &
On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote:
>
> For sure we need to add an EVIOSETPROTO ioctl to allow the driver
> to change the protocol in runtime.
>
Mauro,
I think this kind of confuguration belongs to lirc device space,
not input/evdev. This is the same as proto
On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> > On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote:
> >> For sure we need to add an EVIOSETPROTO ioctl to allow the driver
> >> to cha
On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> > On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote:
> >> Dmitry Torokhov wrote:
> >>> On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Ch
On Wed, Dec 02, 2009 at 10:37:02AM -0500, Jon Smirl wrote:
> On Wed, Dec 2, 2009 at 4:38 AM, Dmitry Torokhov
> wrote:
> > On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro Carvalho Chehab wrote:
> >> Dmitry Torokhov wrote:
> >> > On Tue, Dec 01, 2009 at 05:00:40PM -
On Wed, Dec 02, 2009 at 10:44:58AM -0200, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> > On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro Carvalho Chehab wrote:
> >> Dmitry Torokhov wrote:
> >>> On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab
On Wed, Dec 02, 2009 at 12:30:29PM -0500, Jon Smirl wrote:
> On Wed, Dec 2, 2009 at 12:10 PM, Dmitry Torokhov
> wrote:
> > On Wed, Dec 02, 2009 at 10:44:58AM -0200, Mauro Carvalho Chehab wrote:
> >> Dmitry Torokhov wrote:
> >> > On Tue, Dec 01, 2009 at 07:05:
On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote:
> On 12/2/09 12:30 PM, Jon Smirl wrote:
> (for each remote/substream that they can recognize).
>>
>> I'm assuming that, by remote, you're referring to a remote receiver
>> (and not to
>> the remote itself), rig
On Wed, Dec 02, 2009 at 05:33:34PM -0200, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> >> The raw interface applies only to the devices that doesn't have a hardware
> >> decoder
> >> (something between 40%-60% of the currently supported devices).
>
On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote:
> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
>
> > On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote:
> >> On 12/2/09 12:30 PM, Jon Smirl wrote:
> >>>>>> (for eac
On Wed, Dec 02, 2009 at 03:42:13PM -0500, Jarod Wilson wrote:
> On Dec 2, 2009, at 3:14 PM, Dmitry Torokhov wrote:
>
> > On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote:
> >> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
> >>
> >>>
On Wed, Dec 02, 2009 at 06:23:51PM -0200, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> > On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote:
> >> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
> >>> Now I understand that if 2 remotes send c
On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote:
> Ferenc Wagner wrote:
> > Mauro Carvalho Chehab writes:
>
> We should not forget that simple IR's don't have any key to select the
> address,
> so the produced codes there will never have KEY_TV/KEY_DVD, etc.
Wait, wait, KE
On Thu, Dec 03, 2009 at 01:09:14PM +0100, Gerd Hoffmann wrote:
> On 12/03/09 05:29, Jarod Wilson wrote:
>> On Dec 1, 2009, at 10:28 AM, Gerd Hoffmann wrote:
>>
Anyway, we shouldn't postpone lirc drivers addition due to that.
There are still lots of work to do before we'll be able to split
On Thu, Dec 03, 2009 at 10:51:00PM +0100, Christoph Bartelmus wrote:
> Hi Mauro,
>
> on 03 Dec 09 at 19:10, Mauro Carvalho Chehab wrote:
> [...]
> >>> So the lirc_imon I submitted supports all device types, with the
> >>> onboard decode devices defaulting to operating as pure input devices,
> >>>
On Thu, Dec 03, 2009 at 04:33:28PM -0200, Mauro Carvalho Chehab wrote:
> Let me draw my view:
>
> Em Thu, 3 Dec 2009 09:55:31 -0800
> Dmitry Torokhov escreveu:
>
> > No, please, wait just a minute. I know it is tempting to just merge
> > lirc_dev and start working, bu
On Fri, Dec 04, 2009 at 10:46:00PM +0100, Christoph Bartelmus wrote:
> Hi Mauro,
>
> on 04 Dec 09 at 12:33, Mauro Carvalho Chehab wrote:
> > Christoph Bartelmus wrote:
> Consider passing the decoded data through lirc_dev.
> [...]
> >> Consider cases like this:
> >> http://lirc.sourceforge.net
On Sat, Dec 05, 2009 at 12:01:00AM +0100, Christoph Bartelmus wrote:
> Hi Dmitry,
>
> on 04 Dec 09 at 14:07, Dmitry Torokhov wrote:
> > On Fri, Dec 04, 2009 at 10:46:00PM +0100, Christoph Bartelmus wrote:
> >> Hi Mauro,
> >>
> >> on 04 Dec 09 at 12:33, Ma
Hi,
On Sun, Dec 06, 2009 at 04:36:33AM +0100, hermann pitton wrote:
> Hi,
>
> Am Freitag, den 04.12.2009, 19:28 -0500 schrieb Jon Smirl:
> > On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus
> > wrote:
> > > BTW, I just came across a XMP remote that seems to generate 3x64 bit scan
> > > codes
On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote:
> Em Fri, 4 Dec 2009 02:06:42 -0800
> Dmitry Torokhov escreveu:
>
> > >
> >
> > evdev does not really care what you use as scancode. So nobody stops
> > your driver to report index as
On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote:
> > >
> >
> > How related lirc-core to the current lirc code? If it is not the same
> > maybe we should not call it lirc to avoid confusion.
>
> Just for better illustrate what I'm seeing, I broke the IR generic
> code into tw
On Sun, Dec 06, 2009 at 09:03:31AM -0200, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> > On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote:
> >> Em Fri, 4 Dec 2009 02:06:42 -0800
> >> Dmitry Torokhov escreveu:
> >>
> >>
On Sun, Dec 06, 2009 at 12:58:00PM +0100, Christoph Bartelmus wrote:
> Hi Dmitry,
>
> on 04 Dec 09 at 15:15, Dmitry Torokhov wrote:
> [...]
> >>>>>> http://lirc.sourceforge.net/remotes/lg/6711A20015N
> >>>>>>
> >>>>>> T
On Mon, Dec 07, 2009 at 01:34:10PM -0200, Mauro Carvalho Chehab wrote:
>
> > Scancodes in input system never been real scancodes. Even if you look
> > into atkbd it uses some synthetic data composed out of real scancodes
> > sent to the keyboard, and noone cares. If you are unsatisfied with
> > m
On Sun, Dec 06, 2009 at 09:34:26PM +0100, Krzysztof Halasa wrote:
> Jon Smirl writes:
>
> >> Once again: how about agreement about the LIRC interface
> >> (kernel-userspace) and merging the actual LIRC code first? In-kernel
> >> decoding can wait a bit, it doesn't change any kernel-user interface
On Mon, Dec 07, 2009 at 09:08:57PM +0100, Krzysztof Halasa wrote:
> Dmitry Torokhov writes:
>
> >> There is only one thing which needs attention before/when merging LIRC:
> >> the LIRC user-kernel interface. In-kernel "IR system" is irrelevant and,
> >>
On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
> On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
> > On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
> >
> > > On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
> > >> Krzysztof Halasa wrote:
> > >>> Andy Walls write
On Mon, Dec 07, 2009 at 09:44:14PM -0200, Mauro Carvalho Chehab wrote:
> Let me add my view for those questions.
>
> Jon Smirl wrote:
> > On Sun, Dec 6, 2009 at 3:34 PM, Krzysztof Halasa wrote:
> >> Jon Smirl writes:
> >>
> Once again: how about agreement about the LIRC interface
> (ke
On Tue, Dec 08, 2009 at 09:44:29AM -0200, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> > On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
> >> On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
> >>> On Nov 26, 2009, at 2:43 PM, Andy Walls wr
On Tue, Dec 08, 2009 at 07:52:02AM -0500, Jon Smirl wrote:
> On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls wrote:
> > On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
> >> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
> >
> >> > So I&#x
On Tue, Dec 08, 2009 at 09:58:53AM -0200, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> > On Mon, Dec 07, 2009 at 09:44:14PM -0200, Mauro Carvalho Chehab wrote:
>
> >>> What about capabilities of the receiver, what frequencies?
> >>> If a receiver
On Tue, Dec 08, 2009 at 09:17:42AM -0200, Mauro Carvalho Chehab wrote:
> Jon Smirl wrote:
> > On Mon, Dec 7, 2009 at 6:44 PM, Mauro Carvalho Chehab
> > wrote:
>
> >>> Where is the documentation for the protocol?
> >> I'm not sure what you're meaning here. I've started a doc about IR at the
> >>
On Tue, Dec 08, 2009 at 07:46:52AM -0500, Andy Walls wrote:
> On Tue, 2009-12-08 at 09:32 -0200, Mauro Carvalho Chehab wrote:
> > Andy Walls wrote:
> > > On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
>
> > > So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
> > > end
On Tue, Dec 08, 2009 at 02:57:15PM +0100, Krzysztof Halasa wrote:
> Dmitry Torokhov writes:
>
> > Why woudl we want to do this? Quite often there is a need for "observer"
> > that maybe does not act on data but allows capturing it. Single-user
> > inetrfaces
On Tue, Dec 29, 2009 at 12:04:00AM -0500, Jarod Wilson wrote:
On Dec 28, 2009, at 4:31 AM, Dmitry Torokhov wrote:
Hm, will this work on big-endian?
Good question. Not sure offhand. Probably not. Unfortunately, the
only devices I have to test with at the moment are integrated into
cases
nput.c and for
> >> drivers/media/rc/* that make use of this new key, if its deemed
> >> appropriate for addition. To make it simpler to merge the additional
> >> patches, it would be nice if this could sneak into 2.6.39, and the
> >> rest can then get queued up fo
On Wed, May 11, 2011 at 08:59:16PM +0300, Anssi Hannula wrote:
>
> I meant replacing the softrepeat with native repeat for such devices
> that have native repeats but no native release events:
>
> - keypress from device => keydown + keyup
> - repeat from device => keydown + keyup
> - repeat from
On Sun, Jul 19, 2009 at 02:26:53PM -0400, Mark Lord wrote:
> (resending.. somebody trimmed linux-kernel from the CC: earlier)
>
> Jean Delvare wrote:
>> On Sun, 19 Jul 2009 10:38:37 -0400, Mark Lord wrote:
>>> I'm debugging various other b0rked things in 2.6.31 here right now,
>>> so I had a closer
On Sun, Jul 19, 2009 at 03:20:50PM -0400, Mark Lord wrote:
> Mark Lord wrote:
>> (resending.. somebody trimmed linux-kernel from the CC: earlier)
>>
>> Jean Delvare wrote:
>>> On Sun, 19 Jul 2009 10:38:37 -0400, Mark Lord wrote:
I'm debugging various other b0rked things in 2.6.31 here right no
ave been doing this all along, its just
that it never caused any function difference until the referenced change
went into the input layer.
Reported-by: Stephan Raue
CC: Mauro Carvalho Chehab
CC: Jeff Brown
Signed-off-by: Jarod Wilson
Signed-off-by: Dmitry Torokhov
---
drivers/media/rc/rc-
s another hidden bug in the code
> where we were calling input_report_key using last_keycode instead of our
> just discovered keycode, which manifested with the reordering of calling
> input_report_key and setting last_keycode.
>
> Reported-by: Stephan Raue
> CC: Stephan Raue
On Fri, Jul 01, 2011 at 09:34:45PM +0200, Mauro Carvalho Chehab wrote:
> This is an automatic generated email to let you know that the following patch
> were queued at the
> http://git.linuxtv.org/media_tree.git tree:
>
> Subject: [media] rc: call input_sync after scancode reports
> Author: Jar
On Thu, Jul 07, 2011 at 08:28:12PM -0400, Jarod Wilson wrote:
> On Thu, Jul 7, 2011 at 7:58 PM, Dmitry Torokhov
> wrote:
> > On Fri, Jul 01, 2011 at 09:34:45PM +0200, Mauro Carvalho Chehab wrote:
> >> This is an automatic generated email to let you know that the following
&
On Wed, Apr 28, 2010 at 01:37:00PM -0400, Jarod Wilson wrote:
> Set the EV_REP bit, so reported key repeats actually make their
> way out to userspace, and fix up the handling of repeats a bit,
> routines for which are shamelessly heisted from ati_remote2.c.
>
Is it really needed? I'd expect input
On Mon, May 24, 2010 at 05:23:05PM +0200, Daniel Mack wrote:
> Signed-off-by: Daniel Mack
> Cc: Wolfram Sang
> Cc: Mauro Carvalho Chehab
> Cc: Jiri Slaby
> Cc: Dmitry Torokhov
> Cc: Devin Heitmueller
> Cc: linux-media@vger.kernel.org
Not sure how I got on the list but
Hi Wolfram,
On Mon, May 31, 2010 at 02:55:48PM +0200, Wolfram Sang wrote:
> I2C-drivers can use the clientdata-pointer to point to private data. As I2C
> devices are not really unregistered, but merely detached from their driver, it
> used to be the drivers obligation to clear this pointer during
On Mon, May 31, 2010 at 10:48:32PM +0100, Richard Purdie wrote:
> On Mon, 2010-05-31 at 12:09 -0700, Dmitry Torokhov wrote:
> > On Mon, May 31, 2010 at 02:55:48PM +0200, Wolfram Sang wrote:
> > > I2C-drivers can use the clientdata-pointer to point to private data. As
> >
On Mon, Jul 26, 2010 at 10:13:52AM -0400, Jarod Wilson wrote:
> Per Dmitry Torokhov (in a completely unrelated thread on linux-input),
> following input_unregister_device with an input_free_device is
> forbidden, the former is sufficient alone.
>
> CC: Dmitry Torokhov
> Si
On Thu, Feb 04, 2010 at 11:31:45AM +0100, Jiri Slaby wrote:
+
> +static int dvb_event(struct hid_device *hdev, struct hid_field *field,
> + struct hid_usage *usage, __s32 value)
> +{
> + /* we won't get a "key up" event */
> + if (value) {
> + input_event(field->hid
On Thu, Feb 04, 2010 at 07:33:22PM +0100, Jiri Slaby wrote:
> On 02/04/2010 07:14 PM, Dmitry Torokhov wrote:
> > On Thu, Feb 04, 2010 at 11:31:45AM +0100, Jiri Slaby wrote:
> > +
> >> +static int dvb_event(struct hid_device *hdev, struct hid_field *field,
> >> +
ble
> the coalesce.
>
> Signed-off-by: Jiri Slaby
Looks good.
Acked-by: Dmitry Torokhov
> Cc: Mauro Carvalho Chehab
> Cc: linux-media@vger.kernel.org
> ---
> drivers/media/dvb/dvb-usb/dib0700_core.c |1 +
> drivers/media/dvb/dvb-usb/dvb-usb-remote.c |1 +
>
The HID layer has some scan codes of the form 0xffbc for logitech
devices which do not work if scancode is typed as signed int, so we need
to switch to unsigned int instead. While at it keycode being signed does
not make much sense either.
Signed-off-by: Dmitry Torokhov
---
Guys,
I was
On Sun, Feb 28, 2010 at 07:44:32AM +0100, Németh Márton wrote:
> Hi,
> Dmitry Torokhov wrote:
> > The HID layer has some scan codes of the form 0xffbc for logitech
> > devices which do not work if scancode is typed as signed int, so we need
> > to switch to unsigned
son
>
> There are many many ways one can capitalize "Lifebook B Series"...
>
> Signed-off-by: Jon Dodgson
> Signed-off-by: Dmitry Torokhov
>
> drivers/input/mouse/lifebook.c |6 ++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> ---
>
>
Hi Mauro,
On Thu, Mar 11, 2010 at 12:46:19PM -0300, Mauro Carvalho Chehab wrote:
> In order to allow userspace programs to autoload an IR table, a link is
> needed to point to the corresponding input device.
>
> $ tree /sys/class/irrcv/irrcv0
> /sys/class/irrcv/irrcv0
> |-- current_protocol
> |--
On Fri, Mar 12, 2010 at 01:32:23AM -0300, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> > Hi Mauro,
> >
> > On Thu, Mar 11, 2010 at 12:46:19PM -0300, Mauro Carvalho Chehab wrote:
> >> In order to allow userspace programs to autoload an IR table, a link
On Sat, Mar 13, 2010 at 05:59:34PM -0300, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> > On Fri, Mar 12, 2010 at 01:32:23AM -0300, Mauro Carvalho Chehab wrote:
> >> Dmitry Torokhov wrote:
> >>> Hi Mauro,
> >>>
> >>> On Thu, Mar 11,
Hi Wolfram,
On Mon, Mar 22, 2010 at 07:21:17AM +0100, Wolfram Sang wrote:
> Made necessary by 6992f5334995af474c2b58d010d08bc597f0f2fe.
>
> Found by this semantic patch:
>
> @ init @
> type T;
> identifier A;
> @@
>
> T {
> ...
> struct device_attribute A
On Fri, Mar 26, 2010 at 11:40:41AM -0300, Mauro Carvalho Chehab wrote:
> David Härdeman wrote:
> > On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
> >>>10) extend keycode table replacement to support big/variable
> >>>sized scancodes;
> >> Pending.
> >>
> >>
On Sun, Aug 07, 2011 at 01:18:11AM +0300, Anssi Hannula wrote:
> Add keymap for the Medion X10 RF remote which uses the ati_remote
> driver, and default to it based on the usb id.
Since rc-core supports loading custom keytmaps should we ass medion
keymap here?
I think we should keep the original
media/IR/ir-keytable.c:363: warning: 'retval' may be used
> uninitialized in this function
>
> It is due to an actual bug but I don't know the fix.
>
The patch below should fix it. I wonder if Linus released -rc1 yet...
--
Dmitry
Input: ir-keytable - fix uninitialized varia
On Tue, Nov 02, 2010 at 12:04:56PM -0400, Jarod Wilson wrote:
> On Sun, Oct 31, 2010 at 6:18 PM, Dmitry Torokhov
> wrote:
> > On Sunday, October 31, 2010 10:51:21 am Stefan Richter wrote:
> >> Commit 9f470095068e "Input: media/IR - switch to using new keycode
> >
On Tuesday, November 16, 2010 09:39:09 am Mauro Carvalho Chehab wrote:
> Hi Dmitry,
>
> This patch fixes an IR table. The patch is trivial, but there are two
> buttons on this IR that are not directly supported currently (buttons 10-
> and 10+). In a matter of fact, some other IR's use other key c
ff-by: Dmitry Torokhov
---
drivers/input/evdev.c | 113 +
include/linux/input.h |6 ++-
2 files changed, 62 insertions(+), 57 deletions(-)
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index 17660b1..915287e 100644
--- a/drivers/
On Thu, Dec 09, 2010 at 08:04:36PM +0100, Henrik Rydberg wrote:
> On 12/09/2010 10:39 AM, Dmitry Torokhov wrote:
>
> > The desire to keep old names for the EVIOCGKEYCODE/EVIOCSKEYCODE while
> > extending them to support large scancodes was a mistake. While we tried
> > to
On Thu, Dec 09, 2010 at 11:16:47AM -0800, Dmitry Torokhov wrote:
> On Thu, Dec 09, 2010 at 08:04:36PM +0100, Henrik Rydberg wrote:
> > On 12/09/2010 10:39 AM, Dmitry Torokhov wrote:
> >
> > > The desire to keep old names for the EVIOCGKEYCODE/EVIOCSKEYCODE while
> &g
Hi Nick,
On Wed, Jun 01, 2016 at 05:39:45PM +0100, Nick Dyer wrote:
> Atmel maXTouch devices have a T37 object which can be used to read raw
> touch deltas from the device. This consists of an array of 16-bit
> integers, one for each node on the touchscreen matrix.
>
> Signed-off-by: Nick Dyer
>
On Wed, Jun 01, 2016 at 05:39:48PM +0100, Nick Dyer wrote:
> Register a video device to output T37 diagnostic data.
>
> Signed-off-by: Nick Dyer
> ---
> drivers/input/touchscreen/Kconfig| 2 +
> drivers/input/touchscreen/atmel_mxt_ts.c | 247
> +++
> 2 file
On Wed, Jun 01, 2016 at 05:39:51PM +0100, Nick Dyer wrote:
> The mXT1386 family of chips have a different architecture which splits
> the diagnostic data into 3 columns.
>
> Signed-off-by: Nick Dyer
> ---
> drivers/input/touchscreen/atmel_mxt_ts.c | 29 ++---
> 1 file cha
On Wed, Jun 01, 2016 at 05:39:44PM +0100, Nick Dyer wrote:
> This is a series of patches to add diagnostic data support to the Atmel
> maXTouch driver. It's a rewrite of the previous implementation which output
> via
> debugfs: it now uses a V4L2 device in a similar way to the sur40 driver.
>
> T
On Fri, Jun 17, 2016 at 08:37:38AM -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 17 Jun 2016 13:09:10 +0200
> Hans Verkuil escreveu:
>
> > On 06/17/2016 11:50 AM, Mauro Carvalho Chehab wrote:
> > One area where I am uncertain is when remote control messages are received
> > and
> > passed on by
Hi Hans,
On Sat, Jun 18, 2016 at 04:50:26PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Hi Dmitry,
>
> This patch series adds input support for the HDMI CEC bus through which
> remote control keys can be passed from one HDMI device to another.
>
> This has been posted before as part of
On Sat, Jun 18, 2016 at 02:44:08PM -0300, Mauro Carvalho Chehab wrote:
> Em Sat, 18 Jun 2016 18:56:24 +0200
> Hans Verkuil escreveu:
>
> > On 06/18/2016 06:26 PM, Dmitry Torokhov wrote:
> > > Hi Hans,
> > >
> > > On Sat, Jun 18, 2016 at 04:50:26PM +020
Hi Nick,
On Wed, Jun 22, 2016 at 11:08:32PM +0100, Nick Dyer wrote:
> Function 54 implements access to various RMI4 diagnostic features.
>
> This patch adds support for retrieving this data. It registers a V4L2
> device to output the data to user space.
>
> Signed-off-by: Nick Dyer
> ---
> dri
On Wed, Jun 22, 2016 at 11:08:25PM +0100, Nick Dyer wrote:
> Some touch controllers send out touch data in a similar way to a
> greyscale frame grabber.
>
> Use a new device prefix v4l-touch for these devices, to stop generic
> capture software from treating them as webcams.
>
> Add formats:
> -
On Mon, Jun 29, 2015 at 12:14:50PM +0200, Hans Verkuil wrote:
> Inputs can come in over the HDMI CEC bus, so add a new type for this.
>
> Signed-off-by: Hans Verkuil
Acked-by: Dmitry Torokhov
> ---
> include/uapi/linux/input.h | 1 +
> 1 file changed, 1 insertion(+)
>
&
On Mon, Jun 29, 2015 at 12:14:49PM +0200, Hans Verkuil wrote:
> From: Kamil Debski
>
> Add HDMI CEC specific keycodes to the keycodes definition.
>
> Signed-off-by: Kamil Debski
> Signed-off-by: Hans Verkuil
Could you please describe the intended use for these keycodes for people
who do not l
On Tue, Jun 30, 2015 at 09:36:49AM +0200, Hans Verkuil wrote:
> On 06/29/15 21:25, Dmitry Torokhov wrote:
> > On Mon, Jun 29, 2015 at 12:14:49PM +0200, Hans Verkuil wrote:
> >> From: Kamil Debski
> >>
> >> Add HDMI CEC specific keycodes to the keycodes defini
Hi Javier,
On Thu, Jul 30, 2015 at 06:18:25PM +0200, Javier Martinez Canillas wrote:
> Hello,
>
> Short version:
>
> This series add the missing MODULE_DEVICE_TABLE() for OF and I2C tables
> to export that information so modules have the correct aliases built-in
> and autoloading works correctly
On Thu, Jul 30, 2015 at 09:35:17AM -0700, Dmitry Torokhov wrote:
> Hi Javier,
>
> On Thu, Jul 30, 2015 at 06:18:25PM +0200, Javier Martinez Canillas wrote:
> > Hello,
> >
> > Short version:
> >
> > This series add the missing MODULE_DEVICE_TABLE() f
On Tue, Aug 18, 2015 at 11:00:20AM +0100, Russell King - ARM Linux wrote:
> On Tue, Aug 18, 2015 at 10:26:32AM +0200, Hans Verkuil wrote:
> > + /* Part 2: Initialize and register the character device */
> > + cdev_init(&cecdev->cdev, &cec_devnode_fops);
> > + cecdev->cdev.owner = owner;
> > +
Hi Guenter,
On Sat, Nov 19, 2016 at 07:46:58PM -0800, Guenter Roeck wrote:
> Kasan reports:
>
> BUG: KASAN: slab-out-of-bounds in __fill_v4l2_buffer+0xc3/0x540
> [videobuf2_v4l2] at addr 8806c5e0c6cc
> Read of size 4 by task heatmap/14414
> CPU: 2 PID: 14414 Comm: heatmap Tainted: G
On Sun, Jul 10, 2016 at 03:11:18PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil
>
> This is for the new pulse8-cec staging driver.
>
> Signed-off-by: Hans Verkuil
> Cc: Dmitry Torokhov
Acked-by: Dmitry Torokhov
Please feel free to merge through media tree. If yo
Hi Hans,
On Fri, Jul 15, 2016 at 01:27:21PM +0200, Hans Verkuil wrote:
> For the upcoming 4.8 kernel I made a driver for the Pulse-Eight USB CEC
> adapter.
> This is a usb device that shows up as a ttyACM0 device. It requires that you
> run
> inputattach in order to communicate with it via serio
On Mon, Aug 01, 2016 at 03:43:32PM +0200, Hans Verkuil wrote:
>
>
> On 07/15/2016 06:31 PM, Dmitry Torokhov wrote:
> > Hi Hans,
> >
> > On Fri, Jul 15, 2016 at 01:27:21PM +0200, Hans Verkuil wrote:
> >> For the upcoming 4.8 kernel I made a driver for t
101 - 200 of 226 matches
Mail list logo
