Linux Input/HID development
 help / color / mirror / Atom feed
From: Maxim Levitsky <maximlevitsky@gmail.com>
To: Christoph Bartelmus <lirc@bartelmus.de>
Cc: linux-input@vger.kernel.org, linux-media@vger.kernel.org,
	lirc-list@lists.sourceforge.net, mchehab@redhat.com,
	Jarod Wilson <jarod@wilsonet.com>
Subject: Re: [PATCH 5/9] IR: extend interfaces to support more device settings
Date: Thu, 29 Jul 2010 18:27:07 +0300	[thread overview]
Message-ID: <1280417227.29938.60.camel@maxim-laptop> (raw)
In-Reply-To: <BTlMvkhXqgB@lirc>

On Thu, 2010-07-29 at 09:25 +0200, Christoph Bartelmus wrote: 
> Hi!
> 
> Maxim Levitsky "maximlevitsky@gmail.com" wrote:
> 
> > Also reuse LIRC_SET_MEASURE_CARRIER_MODE as LIRC_SET_LEARN_MODE
> > (LIRC_SET_LEARN_MODE will start carrier reports if possible, and
> > tune receiver to wide band mode)
> 
> I don't like the rename of the ioctl. The ioctl should enable carrier
> reports. Anything else is hardware specific. Learn mode gives a somewhat
> wrong association to me. irrecord always has been using "learn mode"
> without ever using this ioctl.

Why?

Carrier measure (if supported by hardware I think should always be
enabled, because it can help in-kernel decoders).
(Which raises seperate question on how to do so. I guess I will need to
make ir_raw_event 64 bit after all...)


Another thing is reporting these results to lirc.
By default lirc shouldn't get carrier reports, but as soon as irrecord
starts, it can place device in special mode that allows it to capture
input better, and optionally do carrier reports.

Do you think carrier reports are needed by lircd?

Best regards,
Maxim Levitsky


  reply	other threads:[~2010-07-29 15:27 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-28 23:40 (unknown), Maxim Levitsky
2010-07-28 23:40 ` [PATCH 1/9] IR: Kconfig fixes Maxim Levitsky
2010-07-28 23:40 ` [PATCH 2/9] IR: minor fixes: Maxim Levitsky
2010-07-28 23:40 ` [PATCH 3/9] IR: replace spinlock with mutex Maxim Levitsky
2010-07-28 23:40 ` [PATCH 4/9] IR: add helper function for hardware with small o/b buffer Maxim Levitsky
2010-07-28 23:40 ` [PATCH 5/9] IR: extend interfaces to support more device settings Maxim Levitsky
2010-07-29  7:25   ` Christoph Bartelmus
2010-07-29 15:27     ` Maxim Levitsky [this message]
2010-07-29 17:05       ` Christoph Bartelmus
2010-07-28 23:40 ` [PATCH 6/9] IR: Allow not to compile keymaps in Maxim Levitsky
2010-07-28 23:40 ` [PATCH 7/9] IR: report unknown scancodes the in-kernel decoders found Maxim Levitsky
2010-07-28 23:40 ` [PATCH 8/9] STAGING: remove lirc_ene0100 driver Maxim Levitsky
2010-07-28 23:40 ` [PATCH 9/9] IR: Port ene driver to new IR subsystem and enable it Maxim Levitsky
2010-07-29  3:52 ` [PATCH 0/9 v2] IR: few fixes, additions and ENE driver Jarod Wilson
2010-07-29 15:30   ` Maxim Levitsky
2010-07-29 15:26     ` Jarod Wilson
2010-07-29  7:23 ` <kein Betreff> Christoph Bartelmus
2010-07-29 14:41   ` [PATCH 0/9 v2] IR: few fixes, additions and ENE driver Maxim Levitsky
2010-07-29 15:38     ` Andy Walls
2010-07-29 16:26       ` Maxim Levitsky
2010-07-29 16:58         ` Andy Walls
2010-07-29 17:15         ` Christoph Bartelmus
2010-07-29 17:35           ` Maxim Levitsky
2010-07-29 19:35             ` Christoph Bartelmus
2010-07-29 20:04               ` Maxim Levitsky
2010-07-29 21:28                 ` Jarod Wilson
2010-07-29 21:57                   ` Jarod Wilson
2010-07-29 22:07                     ` Maxim Levitsky
2010-07-29 22:24                       ` Maxim Levitsky
2010-07-30  2:03           ` Andy Walls
2010-07-29 17:17       ` Christoph Bartelmus
2010-07-29 16:58     ` Christoph Bartelmus
2010-07-29 17:43       ` Maxim Levitsky
2010-07-29 19:42         ` Christoph Bartelmus
2010-07-29 19:58           ` Maxim Levitsky
2010-07-29 19:21       ` Jarod Wilson
  -- strict thread matches above, loose matches on Subject: below --
2010-07-28 15:14 [PATCH 0/9 v1] " Maxim Levitsky
2010-07-28 15:14 ` [PATCH 5/9] IR: extend interfaces to support more device settings Maxim Levitsky
2010-07-28 17:00   ` Mauro Carvalho Chehab
2010-07-28 20:47   ` Jarod Wilson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1280417227.29938.60.camel@maxim-laptop \
    --to=maximlevitsky@gmail.com \
    --cc=jarod@wilsonet.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=lirc-list@lists.sourceforge.net \
    --cc=lirc@bartelmus.de \
    --cc=mchehab@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox