Re: [PATCH] lirc.4: remove ioctls and feature bits which were never implemented

[Alec Leamas]

Hi all,

On 29/10/18 18:30, Sean Young wrote:
> Hi Michael,
> 
> On Thu, Jul 12, 2018 at 02:21:18PM +0100, Sean Young wrote:
>> On Thu, Jul 12, 2018 at 09:33:32AM -0300, Mauro Carvalho Chehab wrote:
>>> Hi Michael/Alec,
>>>
>>> Em Fri, 18 May 2018 16:25:29 +0100
>>> Sean Young  escreveu:
>>>
 On Sun, May 06, 2018 at 12:34:53PM +0200, Michael Kerrisk (man-opages) 
 wrote:
> [CCing original author of this page]
>
>
> On 04/23/2018 12:26 PM, Sean Young wrote:  
>> The lirc header file included ioctls and feature bits which were never
>> implemented by any driver. They were removed in commit:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d55f09abe24b4dfadab246b6f217da547361cdb6
>>   
>
> Alec, does this patch look okay to you? 

Yes.

I have sent a reply on this (in the same spirit) "long time ago"

>>>
>>> Sean is the sub-maintainer responsible for the LIRC code at the
>>> media subsystem. He knows more about the current implementation
>>> than anyone else, as he's working hard to improve it, and got
>>> rid of all legacy LIRC drivers from staging (either fixing them
>>> or removing the few ones nobody uses anymore).
>>>
>>> As part of his work, some ioctls got removed, in order to make
>>> the LIRC interface to match the real implementation.
>>>  
 Mauro, as Alec is not responding, would you be able to sign this off?
>>>
>>> Most of the patch looks ok on my eyes. I noticed that some flags
>>> still exists at include/uapi/linux/lirc.h:
>>>
>>> LIRC_CAN_REC_RAW, LIRC_CAN_REC_PULSE, LIRC_CAN_SET_REC_FILTER
>>> and LIRC_CAN_SEND_MODE2
>>>
>>> Maybe instead of just removing, you would need to add some
>>> explanation about them (or at the patch itself, explaining
>>> why you're removing the descriptions for them).
>>
>> Those flags do still exist in the header file, we decided to keep them
>> so that code does not suddenly fail to build. These flags either never
>> had implementations or only had out-of-tree implementations. So, I do
>> not think they belong in the man page.
>>
 Alternatively, what can be done to progress this?

 There is some new functionality in lirc which should be added to this man
 page too, so I have more to come (when I get round to writing it).
>>>
>>> Yeah, making it reflect upstream sounds the right thing to do.
>>
>> Absolutely, when kernel v4.18 is released there is more to add.
> 
> Ping, can this patch be merged please?
> 
> The lirc.4 man page is really out of date and misleading in parts. 


Cheers!
--a

IR remote repeat handling broken + patch

[Alec Leamas]

Dear list,

Somewhere between 4.4.7 and 4.6.4 the IR remote repeat events broke. I 
eventually bisected it down to "[078600f] [media] rc-core: allow calling 
rc_open with device not initialized". While going further with this I 
discovered that  a patch had been posted on this list [1].  However, the 
patch is seemingly not reviewed.


Could someone please review this patch? I have tested it myself, and 
Fedora has pulled  the patch in the  branches [2]. The problem is bad, 
blocking many remotes from working as expected in lirc.



Cheers!


--alec


[1] http://www.spinics.net/lists/linux-media/msg103384.html

[2] https://bugzilla.redhat.com/show_bug.cgi?id=1360688

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch is accepted - now what?

[Alec Leamas]

Dear list,

Some time ago I submitted my first kernel patch. When checking,  I now
find that my patch is in state 'accepted' [1].

What I don't understand is what this means, exactly. In particular, does
it mean it eventually will be part of the kernel?

"Confused"

--alec

[1] https://patchwork.linuxtv.org/patch/31865/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Move internal header file lirc.h to uapi/ (#75751).

[Alec Leamas]

The file include/media/lirc.h describes a public interface and
should thus be a public header. See kernel bug
https://bugzilla.kernel.org/show_bug.cgi?id=75751 which has 
a manpage describing the interface + an acknowledgement that this 
info belongs to uapi.

---
 include/media/lirc.h  | 169 +-
 include/uapi/linux/Kbuild |   1 +
 include/uapi/linux/lirc.h | 163 
 3 files changed, 165 insertions(+), 168 deletions(-)
 create mode 100644 include/uapi/linux/lirc.h

diff --git a/include/media/lirc.h b/include/media/lirc.h
index 4b3ab29..554988c 100644
--- a/include/media/lirc.h
+++ b/include/media/lirc.h
@@ -1,168 +1 @@
-/*
- * lirc.h - linux infrared remote control header file
- * last modified 2010/07/13 by Jarod Wilson
- */
-
-#ifndef _LINUX_LIRC_H
-#define _LINUX_LIRC_H
-
-#include 
-#include 
-
-#define PULSE_BIT   0x0100
-#define PULSE_MASK  0x00FF
-
-#define LIRC_MODE2_SPACE 0x
-#define LIRC_MODE2_PULSE 0x0100
-#define LIRC_MODE2_FREQUENCY 0x0200
-#define LIRC_MODE2_TIMEOUT   0x0300
-
-#define LIRC_VALUE_MASK  0x00FF
-#define LIRC_MODE2_MASK  0xFF00
-
-#define LIRC_SPACE(val) (((val)_VALUE_MASK) | LIRC_MODE2_SPACE)
-#define LIRC_PULSE(val) (((val)_VALUE_MASK) | LIRC_MODE2_PULSE)
-#define LIRC_FREQUENCY(val) (((val)_VALUE_MASK) | LIRC_MODE2_FREQUENCY)
-#define LIRC_TIMEOUT(val) (((val)_VALUE_MASK) | LIRC_MODE2_TIMEOUT)
-
-#define LIRC_VALUE(val) ((val)_VALUE_MASK)
-#define LIRC_MODE2(val) ((val)_MODE2_MASK)
-
-#define LIRC_IS_SPACE(val) (LIRC_MODE2(val) == LIRC_MODE2_SPACE)
-#define LIRC_IS_PULSE(val) (LIRC_MODE2(val) == LIRC_MODE2_PULSE)
-#define LIRC_IS_FREQUENCY(val) (LIRC_MODE2(val) == LIRC_MODE2_FREQUENCY)
-#define LIRC_IS_TIMEOUT(val) (LIRC_MODE2(val) == LIRC_MODE2_TIMEOUT)
-
-/* used heavily by lirc userspace */
-#define lirc_t int
-
-/*** lirc compatible hardware features ***/
-
-#define LIRC_MODE2SEND(x) (x)
-#define LIRC_SEND2MODE(x) (x)
-#define LIRC_MODE2REC(x) ((x) << 16)
-#define LIRC_REC2MODE(x) ((x) >> 16)
-
-#define LIRC_MODE_RAW  0x0001
-#define LIRC_MODE_PULSE0x0002
-#define LIRC_MODE_MODE20x0004
-#define LIRC_MODE_LIRCCODE 0x0010
-
-
-#define LIRC_CAN_SEND_RAW  LIRC_MODE2SEND(LIRC_MODE_RAW)
-#define LIRC_CAN_SEND_PULSELIRC_MODE2SEND(LIRC_MODE_PULSE)
-#define LIRC_CAN_SEND_MODE2LIRC_MODE2SEND(LIRC_MODE_MODE2)
-#define LIRC_CAN_SEND_LIRCCODE LIRC_MODE2SEND(LIRC_MODE_LIRCCODE)
-
-#define LIRC_CAN_SEND_MASK 0x003f
-
-#define LIRC_CAN_SET_SEND_CARRIER  0x0100
-#define LIRC_CAN_SET_SEND_DUTY_CYCLE   0x0200
-#define LIRC_CAN_SET_TRANSMITTER_MASK  0x0400
-
-#define LIRC_CAN_REC_RAW   LIRC_MODE2REC(LIRC_MODE_RAW)
-#define LIRC_CAN_REC_PULSE LIRC_MODE2REC(LIRC_MODE_PULSE)
-#define LIRC_CAN_REC_MODE2 LIRC_MODE2REC(LIRC_MODE_MODE2)
-#define LIRC_CAN_REC_LIRCCODE  LIRC_MODE2REC(LIRC_MODE_LIRCCODE)
-
-#define LIRC_CAN_REC_MASK  LIRC_MODE2REC(LIRC_CAN_SEND_MASK)
-
-#define LIRC_CAN_SET_REC_CARRIER   (LIRC_CAN_SET_SEND_CARRIER << 16)
-#define LIRC_CAN_SET_REC_DUTY_CYCLE(LIRC_CAN_SET_SEND_DUTY_CYCLE << 16)
-
-#define LIRC_CAN_SET_REC_DUTY_CYCLE_RANGE 0x4000
-#define LIRC_CAN_SET_REC_CARRIER_RANGE0x8000
-#define LIRC_CAN_GET_REC_RESOLUTION   0x2000
-#define LIRC_CAN_SET_REC_TIMEOUT  0x1000
-#define LIRC_CAN_SET_REC_FILTER   0x0800
-
-#define LIRC_CAN_MEASURE_CARRIER  0x0200
-#define LIRC_CAN_USE_WIDEBAND_RECEIVER0x0400
-
-#define LIRC_CAN_SEND(x) ((x)_CAN_SEND_MASK)
-#define LIRC_CAN_REC(x) ((x)_CAN_REC_MASK)
-
-#define LIRC_CAN_NOTIFY_DECODE0x0100
-
-/*** IOCTL commands for lirc driver ***/
-
-#define LIRC_GET_FEATURES  _IOR('i', 0x, __u32)
-
-#define LIRC_GET_SEND_MODE _IOR('i', 0x0001, __u32)
-#define LIRC_GET_REC_MODE  _IOR('i', 0x0002, __u32)
-#define LIRC_GET_SEND_CARRIER  _IOR('i', 0x0003, __u32)
-#define LIRC_GET_REC_CARRIER   _IOR('i', 0x0004, __u32)
-#define LIRC_GET_SEND_DUTY_CYCLE   _IOR('i', 0x0005, __u32)
-#define LIRC_GET_REC_DUTY_CYCLE_IOR('i', 0x0006, __u32)
-#define LIRC_GET_REC_RESOLUTION_IOR('i', 0x0007, __u32)
-
-#define LIRC_GET_MIN_TIMEOUT   _IOR('i', 0x0008, __u32)
-#define LIRC_GET_MAX_TIMEOUT   _IOR('i', 0x0009, __u32)
-
-#define LIRC_GET_MIN_FILTER_PULSE  _IOR('i', 0x000a, __u32)
-#define LIRC_GET_MAX_FILTER_PULSE  _IOR('i', 0x000b, __u32)
-#define LIRC_GET_MIN_FILTER_SPACE  _IOR('i', 0x000c, __u32)
-#define LIRC_GET_MAX_FILTER_SPACE  _IOR('i', 0x000d, __u32)
-
-/* code length in bits, currently only for LIRC_MODE_LIRCCODE */
-#define LIRC_GET_LENGTH

Re:

[Alec Leamas]

On 12/11/15 18:41, Mauro Carvalho Chehab wrote:
> Em Thu, 12 Nov 2015 18:31:51 +0100
> Alec Leamas <leamas.a...@gmail.com> escreveu:
> 
>> On 12/11/15 18:20, Mauro Carvalho Chehab wrote:
>>> Em Thu, 12 Nov 2015 18:16:18 +0300
>>> Alberto Mardegan <ma...@users.sourceforge.net> escreveu:
>>
>>> Complaining doesn't help at all. We don't read the mailing list to
>>> check for new patches. Instead, we look for them at:
>>> https://patchwork.linuxtv.org/project/linux-media/list/

So, now you find it?!

>>> However, if the emailer breaks the patch (with was the case of the
>>> "tv tuner max2165..." patch), patchwork won't recognize it as a
>>> patch, and we'll only see the e-mail by accident.
>>
>> Ah... that explains why nobody cares about my patch[1]... Is there any
>> way around picky emailers? 
> 
> Use a good one ;) Here, I use claws-mail, with works fine if configured
> to send text-only e-mails and to not break long lines.

Installing claws-mail for this purpose wasn't too hard.

>> Is putting the patch in an attachment OK?
> 
> No, because it doesn't make easy for people to reply with comments.

Fair enough.



Thanks for newbie help. Cheers!

--alec

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re:

[Alec Leamas]

On 12/11/15 18:20, Mauro Carvalho Chehab wrote:
> Em Thu, 12 Nov 2015 18:16:18 +0300
> Alberto Mardegan  escreveu:

> Complaining doesn't help at all. We don't read the mailing list to
> check for new patches. Instead, we look for them at:
>   https://patchwork.linuxtv.org/project/linux-media/list/
> 
> All patches that goes to the ML are automatically stored there, and will be
> handled by one of the (sub-)maintainers. 

> However, if the emailer breaks the patch (with was the case of the
> "tv tuner max2165..." patch), patchwork won't recognize it as a
> patch, and we'll only see the e-mail by accident.

Ah... that explains why nobody cares about my patch[1]... Is there any
way around picky emailers? Is putting the patch in an attachment OK?

Cheers!

--alec


[1] https://bugzilla.kernel.org/show_bug.cgi?id=75751

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH, newbie, HELP] lirc devices: Missing uapi header lirc.h

[Alec Leamas]

On 08/09/15 17:16, Randy Dunlap wrote:

[adding linux-media + Alan Cox]



Thanks for forwarding this message (no reply so far, though). I will be 
on a slow link over the weekend, so I will just be able to listen to the 
linux-media list (sorry...) If anybody is able to answer, please do so 
to the linux-media list.


Cheers!

--alec

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html