justme123
Posts: 25
Joined: Tue May 02, 2017 8:13 pm

lirc_rpi.c won't compile under latest media_tree & 4.9.28v7+

Thu Jun 29, 2017 10:06 pm

Hi there,

After almost 2 years of frequent kernel updates and successful compilation of my patched media drivers on my non-raspbian Linux distro, I'm struggling now to compile lirc_rpi.c under the updated gcc 7.1.0 & kernel 4.9.28-v7+ and failing with some compiler error messages. I have manually inserted lirc_rpi.c into the media_build as part of my DVB drivers patch routine by modifying the build script and the afferent rc makefile ( I just need this inclusion since lirc_rpi depends on rc_core, which gets re-built during the media_drivers compilation and the kernel is compiled with CONFIG_MODVERSIONS enabled - a brilliant decision BTW!)

My compilation is failing with the following error message:

CC [M] /kit/media_build/v4l/lirc_rpi.o
/kit/media_build/v4l/ati_remote.c: In function 'ati_remote_probe':
/kit/media_build/v4l/ati_remote.c:882:4: warning: ' mouse' directive output may be truncated writing 6 bytes into a region of size between 1 and 80 [-Wformat-truncation=]
"%s mouse", ati_remote->rc_name);
^~~~~~~~~~
/kit/media_build/v4l/ati_remote.c:881:2: note: 'snprintf' output between 7 and 86 bytes into a destination of size 80
snprintf(ati_remote->mouse_name, sizeof(ati_remote->mouse_name),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%s mouse", ati_remote->rc_name);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CC [M] /kit/media_build/v4l/redrat3.o
CC [M] /kit/media_build/v4l/streamzap.o
/kit/media_build/v4l/lirc_rpi.c:569:3: error: 'struct lirc_driver' has no member named 'sample_rate'
.sample_rate = 0,
^~~~~~~~~~~
/kit/media_build/v4l/lirc_rpi.c:571:3: error: 'struct lirc_driver' has no member named 'add_to_buf'
.add_to_buf = NULL,
^~~~~~~~~~
In file included from ./include/uapi/linux/posix_types.h:4:0,
from ./include/uapi/linux/types.h:13,
from ./include/linux/compiler.h:224,
from /kit/media_build/v4l/compat.h:9,
from <command-line>:0:
./include/linux/stddef.h:7:14: warning: initialization makes integer from pointer without a cast [-Wint-conversion]
#define NULL ((void *)0)
^
/kit/media_build/v4l/lirc_rpi.c:571:16: note: in expansion of macro 'NULL'
.add_to_buf = NULL,
^~~~
./include/linux/stddef.h:7:14: note: (near initialization for 'driver.min_timeout')
#define NULL ((void *)0)
^
/kit/media_build/v4l/lirc_rpi.c:571:16: note: in expansion of macro 'NULL'
.add_to_buf = NULL,
^~~~
/kit/media_build/v4l/lirc_rpi.c:573:3: error: 'struct lirc_driver' has no member named 'set_use_inc'
.set_use_inc = set_use_inc,
^~~~~~~~~~~
/kit/media_build/v4l/lirc_rpi.c:573:17: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.set_use_inc = set_use_inc,
^~~~~~~~~~~
/kit/media_build/v4l/lirc_rpi.c:573:17: note: (near initialization for 'driver.rdev')
/kit/media_build/v4l/lirc_rpi.c:574:3: error: 'struct lirc_driver' has no member named 'set_use_dec'
.set_use_dec = set_use_dec,
^~~~~~~~~~~
/kit/media_build/v4l/lirc_rpi.c:574:17: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.set_use_dec = set_use_dec,
^~~~~~~~~~~
/kit/media_build/v4l/lirc_rpi.c:574:17: note: (near initialization for 'driver.fops')
cc1: some warnings being treated as errors
make[3]: *** [scripts/Makefile.build:299: /kit/media_build/v4l/lirc_rpi.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [Makefile:1490: _module_/kit/media_build/v4l] Error 2
make[2]: Leaving directory '/usr/src/linux-headers-4.9.28-v7+'
make[1]: *** [Makefile:53: default] Error 2
make[1]: Leaving directory '/kit/media_build/v4l'
make: *** [Makefile:26: all] Error 2
build failed at ./build line 522

Just for testing, I have modified the source code by commenting out the affected struct definitions:
static struct lirc_driver driver = {
<------>.name<-><------>= LIRC_DRIVER_NAME,
<------>.minor<><------>= -1,
<------>.code_length<-->= 1,
/*<---->.sample_rate<-->= 0, */
<------>.data<-><------>= NULL,
/*<---->.add_to_buf<--->= NULL, */
<------>.rbuf<-><------>= &rbuf,
/*<---->.set_use_inc<-->= set_use_inc, */
/*<---->.set_use_dec<-->= set_use_dec, */
<------>.fops<-><------>= &lirc_fops,
<------>.dev<--><------>= NULL,
<------>.owner<><------>= THIS_MODULE,
};

- restarted the compilation and got some warnings instead of errors:

CC [M] /kit/media_build/v4l/lirc_rpi.o
/kit/media_build/v4l/ati_remote.c: In function 'ati_remote_probe':
/kit/media_build/v4l/ati_remote.c:882:4: warning: ' mouse' directive output may be truncated writing 6 bytes into a region of size between 1 and 80 [-Wformat-truncation=]
"%s mouse", ati_remote->rc_name);
^~~~~~~~~~
/kit/media_build/v4l/ati_remote.c:881:2: note: 'snprintf' output between 7 and 86 bytes into a destination of size 80
snprintf(ati_remote->mouse_name, sizeof(ati_remote->mouse_name),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%s mouse", ati_remote->rc_name);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CC [M] /kit/media_build/v4l/redrat3.o
CC [M] /kit/media_build/v4l/streamzap.o
/kit/media_build/v4l/lirc_rpi.c:464:13: warning: 'set_use_dec' defined but not used [-Wunused-function]
static void set_use_dec(void *data)
^~~~~~~~~~~
/kit/media_build/v4l/lirc_rpi.c:430:12: warning: 'set_use_inc' defined but not used [-Wunused-function]
static int set_use_inc(void *data)
^~~~~~~~~~~

In the end the module was successfully built and loaded by the kernel - without any warns/errs, but it was not working.

I checked Raspberry's git for an updated version of lirc_rpi.c and was not able to find any newer than the one I already have.
Is there any other place to look after an update?
The source code doesn't look to have any version info in the header and the copyright holders are:
* Copyright (C) 2012 Aron Robert Szabo <aron@reon.hu>,
* Michael Bishop <cleverca22@gmail.com>
Hopefully they're still alive, doing well and maintaining the code - should I contact them directly ?


Thank you in advance!
Last edited by justme123 on Fri Jun 30, 2017 4:57 pm, edited 1 time in total.
unregistered user

last topic got vandalized & I got banned by an infantile mod

sorry, I have standards

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7456
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: lirc_rpi.c won't compile under gcc 7.1.0 & kernel 4.9.28

Fri Jun 30, 2017 8:13 am

(Not device tree related at all, but never mind)

If you're building the media_build from linuxtv.org/media_tree, then if you check the history you'll see commit

Code: Select all

commit 2c5a1f44667b75e75302d87e61b335e68f4078f1
Author: David Härdeman <david@hardeman.nu>
Date:   Mon May 1 13:03:46 2017 -0300

    [media] lirc_dev: remove unused set_use_inc/set_use_dec
    
    Since there are no users of this functionality, it can be removed
    altogether.
    
    Signed-off-by: David Härdeman <david@hardeman.nu>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
and

Code: Select all

commit c3104e1b42744156c414003043587d128de2b91f
Author: David Härdeman <david@hardeman.nu>
Date:   Mon May 1 13:03:56 2017 -0300

    [media] lirc_dev: remove sampling kthread
    
    There are no drivers which use this functionality.
    
    Signed-off-by: David Härdeman <david@hardeman.nu>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
which removes sample_rate and add_to_buf.
Your driver is trying to use/implement those removed functions, so it fails to compile. Just removing them leaves almost no driver, so it's unsurprising that it doesn't work.

There appears to be a moderately active GIthub repo with the file at https://github.com/bengtmartensson/lirc_rpi, so you could raise an issue there. Alternatively you could try reverting the two commits mentioned above and see if the framework comes back to life.

There's almost never version info in the headers - that's what git history is for.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

justme123
Posts: 25
Joined: Tue May 02, 2017 8:13 pm

Re: lirc_rpi.c won't compile under gcc 7.1.0 & kernel 4.9.28

Fri Jun 30, 2017 3:20 pm

@ 6by9
Thank you for your reply and clarifications.
I'm sorry to hear that the lirc_rpi.c is not recognized as specific for the RPi board / SoC and is not comprised in its device tree.

"If you're building the media_build from linuxtv.org/media_tree, then if you check the history you'll see commit"
I don't know how to do it differently and not sure actually if there is an alternative. I just need to patch a DVB tuner file and the only way to do it without recompiling the whole RPi kernel is to get the media_tree from git, patch the tuner and rebuild it entirely.
The issue is the lirc_rpi, as it depends on rc_core which is getting rebuilt with different symbols and then when the kernel tries to load lirc_rpi, rc_core is disagreeing about its symbol versions. That's why I hacked the media_build build scripts and inserted the lirc_rpi.c into the build.

Thank you for highlighting the media_tree commits. I wasn't sure if it's the RPi kernel headers or the media_tree ones that caused the issue. I'll try now to address the folks at media_tree and ask them to get those functions back, because they are still used/required.
Obviously, as stated, I commented those lines just for test purposes - I didn't expect the driver to work.

Indeed, disregarding the convenience/laziness, it's a sad development depending entirely on git. Might be that during a git outage the world is gonna end...
:o

Thanks again for your inputs!
unregistered user

last topic got vandalized & I got banned by an infantile mod

sorry, I have standards

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2448
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: lirc_rpi.c won't compile under gcc 7.1.0 & kernel 4.9.28

Fri Jun 30, 2017 3:37 pm

Indeed, disregarding the convenience/laziness, it's a sad development depending entirely on git. Might be that during a git outage the world is gonna end...
"depending entirely on git" is like saying "depending entirely on electricity" - Git was designed from the ground up to be completely distributed with no single point of failure. If one Git server goes down all that happens is that you can no longer get updates from it or publish to it, so you either continue to work locally until it comes back (light a candle) or you add a mirror as a second remote (start the generator) and carry on as before.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7456
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: lirc_rpi.c won't compile under gcc 7.1.0 & kernel 4.9.28

Fri Jun 30, 2017 3:50 pm

justme123 wrote:I'm sorry to hear that the lirc_rpi.c is not recognized as specific for the RPi board / SoC and is not comprised in its device tree.
Half the time it is that people haven't submitted their drivers to either our tree or mainline, they are just pet projects that fall into obscurity. This is the first time I've come across lirc_rpi.
justme123 wrote:"If you're building the media_build from linuxtv.org/media_tree, then if you check the history you'll see commit"
I don't know how to do it differently and not sure actually if there is an alternative. I just need to patch a DVB tuner file and the only way to do it without recompiling the whole RPi kernel is to get the media_tree from git, patch the tuner and rebuild it entirely.
The issue is the lirc_rpi, as it depends on rc_core which is getting rebuilt with different symbols and then when the kernel tries to load lirc_rpi, rc_core is disagreeing about its symbol versions. That's why I hacked the media_build build scripts and inserted the lirc_rpi.c into the build.
media_build is the absolute latest and greatest V4L2 and DVB development tree. That is what will be going in to kernel 4.12.
RPi is currently using 4.9 as that is the current latest that has been blessed with Long Term Support (LTS) status so should be maintained for several (2 IIRC) years. 4.14 is due to be the next to get that status.
media_build is therefore ahead of the Pi tree, and whilst they fix up all drivers that are in the mainline kernel whenever they make an API change, they can't do that for these random "out-of-tree" drivers that people have written.

TBH I'd download the main Pi 4.9 kernel, patch, and rebuild that. OK it's painful on a Pi0 or 1, but on a Pi2 or 3 a full kernel build is under 2 hours (admittedly I was using an NFS mount for storage. It may be worse using an SD card). If cross compiling then it's 20minutes on a fast x86 PC.
justme123 wrote:Thank you for highlighting the media_tree commits. I wasn't sure if it's the RPi kernel headers or the media_tree ones that caused the issue. I'll try now to address the folks at media_tree and ask them to get those functions back, because they are still used/required.
I think you'll be fighting a losing battle there. Have a look through the linux-media mailing list archives to try and track back for any discussion around the changes. https://www.spinics.net/lists/linux-med ... 15088.html looks like a decent start point. There may well be other drivers that have been through the same conversion process already.
justme123 wrote:Indeed, disregarding the convenience/laziness, it's a sad development depending entirely on git. Might be that during a git outage the world is gonna end...
:o
??!?! The Linux kernel source control is all based on git, indeed it was Linux Torvalds who wrote it.
If you're refering to Github, then that's equally bizarre as it is one of the main hosting sites for git repos. And seeing as git is distributed, if it is down then it removes the ability to manage contributions, but doesn't stop any individual developer who has their own local copy.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

justme123
Posts: 25
Joined: Tue May 02, 2017 8:13 pm

Re: lirc_rpi.c won't compile under gcc 7.1.0 & kernel 4.9.28

Fri Jun 30, 2017 3:57 pm

Dear Mr. Engineer PhilE from Cambridge, please take a look on Wikipedia and learn about git's inception and purpose. Github, the commercial implementation of git is not really as reliable and well performing as you might want to believe, or as you might have experienced it in Cambridge. I'd suggest you to leave your comfort from Cambridge and go somewhere in E-Europe/Asia and you'll surely start to question your github enthusiasm, especially while at customer's premises being in a hurry/pressure and experiencing timeouts and transfer rates of some bytes/s, not to mention github censorship.

Sorry for the off-topic - I wasn't starting it, just replying ;)
Last edited by justme123 on Fri Jun 30, 2017 4:55 pm, edited 1 time in total.
unregistered user

last topic got vandalized & I got banned by an infantile mod

sorry, I have standards

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2448
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: lirc_rpi.c won't compile under gcc 7.1.0 & kernel 4.9.28

Fri Jun 30, 2017 4:08 pm

GitHub is not Git - it is just one of many sites hosting Git content. kernel.org is another common one.

If GitHub went down tomorrow we would be massively inconvenienced - but we wouldn't lose any work. Because of the way Git works, the entire contents of our repos will be replicated many times, in our offices and around the world. There are thousands of off-site backups of our Linux repo.

justme123
Posts: 25
Joined: Tue May 02, 2017 8:13 pm

Re: lirc_rpi.c won't compile under gcc 7.1.0 & kernel 4.9.28

Fri Jun 30, 2017 4:40 pm

@6by9

"media_build is the absolute latest and greatest V4L2 and DVB development tree. That is what will be going in to kernel 4.12.
RPi is currently using 4.9 as that is the current latest that has been blessed with Long Term Support (LTS) status so should be maintained for several (2 IIRC) years. 4.14 is due to be the next to get that status.
media_build is therefore ahead of the Pi tree, and whilst they fix up all drivers that are in the mainline kernel whenever they make an API change, they can't do that for these random "out-of-tree" drivers that people have written. "

Thank you for the good news! I'm pretty sure that if you (RPi Foundation) will let them know officially about the lirc_pi implementation and that RPi is widely used (over 10 million units sold), they'll incorporate lirc_pi in their tree. Well, at least it's worth trying, again, officially. I'm aware that I won't have any chance on my own, well, at least I'm' sure I'll be able to annoy them. ;)

As for me, I'm in a special unfortunate situation. I own a well performing (no need to change) Technisat Skystar USB 2 HD CI DVB Tuner that is unsupported but has a rejected patch that makes it work flawlessly. It's an old, at the time of purchase pretty expensive, DVB tuner that has two internal tuners, one for DVB-S and one for DVB-S2, and was presumably bought by Technisat form some Chinese manufacturer and re-branded. What Technisat did wrong was to mess up the internal firmware and that's why it needs a patch.

https://www.linuxtv.org/wiki/index.php/ ... SB_2_HD_CI
"To make DVB-S2 working, you have to compile the recent drivers from git://linuxtv.org/media_build.git with the following patch: https://patchwork.linuxtv.org/patch/22003/ - the patch has been rejected because of the bad quality, but is currently your only chance to make it working. (and is working fine, at least with my two tuners (Rev. 1 and 2))"

Regarding the kernel compilation, I'm doing it all the time on x86 systems under Slackware. Is just that for RPi it's a little bit over-complicated mainly due to the proprietary Broadcom blobs structure/availability and the ARM toolchain (I'm still not sure which one to use, as there are several ones). I was happy with the media_build recompilation until now - it took me 15-20 minutes to get the new kernel, kernel headers and media_build compiled.

I guess I'll stick with my actual working (tuner patched & lirc_pi working) 4.4.50-v7+ for the moment.


[ 5.202838] WARNING: You are using an experimental version of the media stack.
As the driver is backported to an older kernel, it doesn't offer
enough quality for its usage in production.
Use it with care.
Latest git patches (needed if you report a bug to linux-media@vger.kernel.org):
3622d3e77ecef090b5111e3c5423313f11711dfa [media] ov2640: print error if devm_*_optional*() fails
9eb9db3a0f92b75ec710066202e0b2accb45afa9 [media] atmel-isc: Fix the static checker warning
d72b196f96e2afad1656c9332da7ffe3b07e17cb [media] ov2640: add support for MEDIA_BUS_FMT_YVYU8_2X8 and MEDIA_BUS_FMT_VYUY8_2X8
[ 5.331116] lirc_dev: IR Remote Control driver registered, major 244
[ 5.646847] bcm2835-wdt 3f100000.watchdog: Broadcom BCM2835 watchdog timer
[ 5.663313] bcm2708_i2c 3f804000.i2c: BSC1 Controller at 0x3f804000 (irq 83) (baudrate 100000)
[ 5.678806] gpiomem-bcm2835 3f200000.gpiomem: Initialised: Registers at 0x3f200000
[ 5.717812] i2c /dev entries driver
[ 6.240042] media: Linux media interface: v0.10
[ 6.283005] WARNING: You are using an experimental version of the media stack.
As the driver is backported to an older kernel, it doesn't offer
enough quality for its usage in production.
Use it with care.
Latest git patches (needed if you report a bug to linux-media@vger.kernel.org):
3622d3e77ecef090b5111e3c5423313f11711dfa [media] ov2640: print error if devm_*_optional*() fails
9eb9db3a0f92b75ec710066202e0b2accb45afa9 [media] atmel-isc: Fix the static checker warning
d72b196f96e2afad1656c9332da7ffe3b07e17cb [media] ov2640: add support for MEDIA_BUS_FMT_YVYU8_2X8 and MEDIA_BUS_FMT_VYUY8_2X8
[ 6.438929] lirc_rpi: auto-detected active low receiver on GPIO pin 17
[ 6.455628] lirc_rpi lirc_rpi: lirc_dev: driver lirc_rpi registered at minor = 0
[ 6.468636] lirc_rpi: driver registered!
[ 11.538744] dvb-usb: found a 'Technisat SkyStar USB 2 HD CI' in cold state, will try to load a firmware
[ 11.556055] dvb-usb: downloading firmware from file 'dvb-usb-az6027-03.fw'
[ 11.572171] random: nonblocking pool is initialized
[ 11.637646] dvb-usb: found a 'Technisat SkyStar USB 2 HD CI' in warm state.
[ 11.650537] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
[ 11.855770] dvbdev: DVB: registering new adapter (Technisat SkyStar USB 2 HD CI)
[ 11.868638] usb 1-1.5: media controller created
[ 11.880890] dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered.
[ 12.595075] stb0899_attach: Attaching STB0899
[ 12.605021] stb6100_attach: Attaching STB6100
[ 12.614852] dvbdev: dvb_create_media_entity: media entity 'dvb-ca-en50221' registered.
[ 12.629073] usb 1-1.5: DVB: registering adapter 0 frontend 0 (STB0899 Multistandard)...
[ 12.646118] dvbdev: dvb_create_media_entity: media entity 'STB0899 Multistandard' registered.
[ 12.666083] dvb-usb: Technisat SkyStar USB 2 HD CI successfully initialized and connected.
[ 12.680309] usbcore: registered new interface driver dvb_usb_az6027

Thanks again for all your help!
unregistered user

last topic got vandalized & I got banned by an infantile mod

sorry, I have standards

justme123
Posts: 25
Joined: Tue May 02, 2017 8:13 pm

Re: lirc_rpi.c won't compile under latest media_tree & 4.9.2

Fri Jun 30, 2017 5:23 pm

@PhilE

Just to avoid having my point of view misunderstood.
I do appreciate git&github for its aid in the development process. As you stated, even during an outage you're still able to work on your project, and then once available again synchronize and update your commits.
What I'm blaming, is the extensive use of git for distribution purposes, especially within the Raspberry Pi project. Many projects, including kernel.org are usually packing the results and making them available as a tarball - spread and distributed through a bunch of ftp mirrors, which are more reliable (simpler protocol) than github.
Besides, regarding some extra info, like the missing versioning and details, it's worth taking a look at the latest developments of the raspbian release notes:
https://downloads.raspberrypi.org/raspb ... _notes.txt
"* New kernel and firmware"
Very informative! At least some months ago you got some more infos / links on github.
Now I get the kernel version only after I download the image and mount it to extract the kernel and use it in my own linux distro.

Have a good evening!
unregistered user

last topic got vandalized & I got banned by an infantile mod

sorry, I have standards

Barf
Posts: 8
Joined: Tue Dec 06, 2016 11:42 am

Re: lirc_rpi.c won't compile under latest media_tree & 4.9.2

Fri Jun 30, 2017 6:16 pm

There appears to be a moderately active GIthub repo with the file at https://github.com/bengtmartensson/lirc_rpi, so you could raise an issue there.
Well, that is my repos :-). @just123 mailed me, so I will write down some comments

The "official lirc_rpi-thead is this.
lirc_rpi depends on rc_core,
If I understand correctly, my version does not. Possibly it should...

The original compile log contains 4 errors, all of them the assignment of struct fields that have been eliminated. The first two are almost certainly meaningless (i.e. just remove them), the third and forth are explained in the two commit comments from David Härdeman, so they can probably be nuked too.

But you tried that:
In the end the module was successfully built and loaded by the kernel - without any warns/errs, but it was not working.
Hard to help with such an error description... Can be a _real_ problem.

justme123
Posts: 25
Joined: Tue May 02, 2017 8:13 pm

Re: lirc_rpi.c won't compile under latest media_tree & 4.9.2

Fri Jun 30, 2017 6:45 pm

@Barf

Danke for your follow-up!

Here's an excerpt - remote control related form my actually loaded modules (working & compiled before the latest media_build commits):
lsmod:
........
lirc_rpi 6442 2
lirc_dev 7455 1 lirc_rpi
uio_pdrv_genirq 3164 0
rc_core 22647 2 lirc_dev,dvb_usb

I do remember during my first attempts from last year, that either lirc_dev or rc_core was complaining about the original (the one that came with the RPi kernel) lirc_rpi with "disagrees about version of symbol module_layout". Then I went and included it in the media_build and recompiled it. I haven't had any issues ever since, until yesterday as I cloned the latest media_build and went through my " secret recipe".

I'm sure that after commenting out those struct lines, the module lirc_pi module was built and loaded by the kernel but was not working. lircd was running, Kodi was not responding to any RC key press and
irw /var/run/lirc/lircd
was not showing any activity.

I'll try to clone an older version of media_build, one that was not affected by the latest commits. Not sure how to identify it yet, but I'll get over it.

Nice evening @ all!
unregistered user

last topic got vandalized & I got banned by an infantile mod

sorry, I have standards

justme123
Posts: 25
Joined: Tue May 02, 2017 8:13 pm

Re: lirc_rpi.c won't compile under latest media_tree & 4.9.2

Fri Jun 30, 2017 7:16 pm

@Barf & @6by9

Just for clarification, I've been using the original lirc_rpi.c from:

https://github.com/raspberrypi/linux/bl ... lirc_rpi.c

and NOT the updated:

https://github.com/bengtmartensson/lirc ... lirc_rpi.c

I'm realizing now that I have raised the issue with @Barf out of confusion and I'm sorry for that. @6by9 hinted that there might be a newer version of the driver and I understood that @Barf is the latest maintainer/contributor. My bad!
I'll give a try with Barf's version later and update the thread.

brb
unregistered user

last topic got vandalized & I got banned by an infantile mod

sorry, I have standards

Barf
Posts: 8
Joined: Tue Dec 06, 2016 11:42 am

Re: lirc_rpi.c won't compile under latest media_tree & 4.9.2

Fri Jun 30, 2017 7:19 pm

Here is a thing to try: Assuming that you have access to an "old" system, find out if set_use_inc/set_use_dec are called (printk for example). If so, then just nuking it is probably not a good idea.

Checked the dts configuration?

Are you 100% sure that your Lirc works? Try to test the driver without Lirc. In particular, does /dev/lirc0 exist?

HiassofT
Posts: 221
Joined: Fri Jun 30, 2017 10:07 pm
Location: Salzburg, Austria
Contact: Website

Re: lirc_rpi.c won't compile under latest media_tree & 4.9.2

Fri Jun 30, 2017 10:17 pm

FYI: if you don't need the IR blasting functionality of lirc_rpi I'd recommend using gpio-ir-recv (gpio-ir DT overlay) instead. This driver is included in upstream kernel, is part of the rc subsystem and thus supports in-kernel decoding as well. For most common remotes (eg rc6 MCE remotes) you don't need to run userspace lircd but can just configure the rc map via a DT parameter (or use ir-keytable in linux).

so long,

Hias

justme123
Posts: 25
Joined: Tue May 02, 2017 8:13 pm

Re: lirc_rpi.c won't compile under latest media_tree & 4.9.2

Sat Jul 01, 2017 2:01 am

@HiassofT
Thanks for joining the forum just to add your suggestion. An interesting one for sure, I'll take a look into it.
I have a question about it - does it depend on lirc_dev or rc_core ? If yes, then I'll need to recompile it too, together with the whole media_tree stuff and hope that it won't require some "already cleaned during the code optimization" dependencies from media_tree.
As for lircd, it looks like Kodi doesn't really know how to handle a remote without it.

@Barf
I tried your Version (commented the affected lines - as in the post above) and got the same result like with the official one, it gets built, the kernel loads the module but it doesn't work.
/dev/lirc0 does exist!

- compilation:
CC [M] /kit/media_build/v4l/lirc_rpi.o
/kit/media_build/v4l/ati_remote.c: In function 'ati_remote_probe':
/kit/media_build/v4l/ati_remote.c:882:4: warning: ' mouse' directive output may be truncated writing 6 bytes into a region of size between 1 and 80 [-Wformat-truncation=]
"%s mouse", ati_remote->rc_name);
^~~~~~~~~~
/kit/media_build/v4l/ati_remote.c:881:2: note: 'snprintf' output between 7 and 86 bytes into a destination of size 80
snprintf(ati_remote->mouse_name, sizeof(ati_remote->mouse_name),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%s mouse", ati_remote->rc_name);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CC [M] /kit/media_build/v4l/redrat3.o
CC [M] /kit/media_build/v4l/streamzap.o
/kit/media_build/v4l/lirc_rpi.c:493:13: warning: 'set_use_dec' defined but not used [-Wunused-function]
static void set_use_dec(void *data)
^~~~~~~~~~~
/kit/media_build/v4l/lirc_rpi.c:459:12: warning: 'set_use_inc' defined but not used [-Wunused-function]
static int set_use_inc(void *data)
^~~~~~~~~~~

- dmesg:
[ 5.059437] rc_core: loading out-of-tree module taints kernel.
[ 5.088155] WARNING: You are using an experimental version of the media stack.
As the driver is backported to an older kernel, it doesn't offer
enough quality for its usage in production.
Use it with care.
Latest git patches (needed if you report a bug to linux-media@vger.kernel.org):
2748e76ddb2967c4030171342ebdd3faa6a5e8e8 media: staging: cxd2099: Activate cxd2099 buffer mode
3e8d8a085ff454527a422aafe9b7dcfa95c09cc5 media: staging: cxd2099: Removed printing in write_block
6475483734d86f88848fcd61db3d4c35123abcba media: staging: cxd2099: Removed useless printing in cxd2099 driver
[ 5.207711] lirc_dev: IR Remote Control driver registered, major 243
[ 5.586965] gpiomem-bcm2835 3f200000.gpiomem: Initialised: Registers at 0x3f200000
[ 5.659981] i2c /dev entries driver
[ 6.244217] media: Linux media interface: v0.10
[ 6.330631] lirc_rpi: auto-detected active low receiver on GPIO pin 17
[ 6.345514] lirc_rpi lirc_rpi: lirc_dev: driver lirc_rpi registered at minor = 0
[ 6.357960] lirc_rpi: driver registered!
[ 6.458375] WARNING: You are using an experimental version of the media stack.
As the driver is backported to an older kernel, it doesn't offer
enough quality for its usage in production.
Use it with care.
Latest git patches (needed if you report a bug to linux-media@vger.kernel.org):
2748e76ddb2967c4030171342ebdd3faa6a5e8e8 media: staging: cxd2099: Activate cxd2099 buffer mode
3e8d8a085ff454527a422aafe9b7dcfa95c09cc5 media: staging: cxd2099: Removed printing in write_block
6475483734d86f88848fcd61db3d4c35123abcba media: staging: cxd2099: Removed useless printing in cxd2099 driver
[ 11.690427] dvb-usb: found a 'Technisat SkyStar USB 2 HD CI' in cold state, will try to load a firmware
[ 11.707826] dvb-usb: downloading firmware from file 'dvb-usb-az6027-03.fw'
[ 11.775233] dvb-usb: found a 'Technisat SkyStar USB 2 HD CI' in warm state.
[ 11.787911] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
[ 11.993393] dvbdev: DVB: registering new adapter (Technisat SkyStar USB 2 HD CI)
[ 12.005986] usb 1-1.5: media controller created
[ 12.017810] dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered.
[ 12.756727] stb0899_attach: Attaching STB0899
[ 12.766447] stb6100_attach: Attaching STB6100
[ 12.776045] dvbdev: dvb_create_media_entity: media entity 'dvb-ca-en50221' registered.
[ 12.790028] usb 1-1.5: DVB: registering adapter 0 frontend 0 (STB0899 Multistandard)...
[ 12.803346] dvbdev: dvb_create_media_entity: media entity 'STB0899 Multistandard' registered.
[ 12.819574] dvb-usb: Technisat SkyStar USB 2 HD CI successfully initialized and connected.
[ 12.833500] usbcore: registered new interface driver dvb_usb_az6027

- lsmod:

lirc_rpi 8189 2
lirc_dev 8962 1 lirc_rpi
rc_core 31139 2 dvb_usb,lirc_dev

- modinfo lirc_rpi
filename: /lib/modules/4.9.28-v7+/kernel/drivers/staging/media/lirc/lirc_rpi.ko
license: GPL
author: Bengt Martensson <barf@bengt-martensson.de>
author: Michael Bishop <cleverca22@gmail.com>
author: Aron Robert Szabo <aron@reon.hu>
description: Infra-red receiver and blaster driver for Raspberry Pi GPIO.
srcversion: 533BB7E5866E52F63B9ACCB
alias: of:N*T*Crpi,lirc-rpiC*
alias: of:N*T*Crpi,lirc-rpi
depends: lirc_dev
vermagic: 4.9.28-v7+ SMP mod_unload modversions ARMv7 p2v8
parm: gpio_out_pin:GPIO output/transmitter pins of the BCM processor. (default 17) (array of int)
parm: gpio_in_pin:GPIO input pin number of the BCM processor. (default 18) (int)
parm: gpio_in_pull:GPIO input pin pull configuration. (0 = off, 1 = up, 2 = down, default down) (int)
parm: sense:Override autodetection of IR receiver circuit (0 = active high, 1 = active low ) (int)
parm: softcarrier:Software carrier (0 = off, 1 = on, default on) (bool)
parm: invert:Invert output (0 = off, 1 = on, default off (bool)
parm: debug:Enable debugging messages (bool)


I found an older backup of an already compiled media_build directory and checked its repo version - it was from the 2nd of march 2017. I then tried to clone that version of media_tree just to find out that the build script doesn't really like older media_tree versions. I lost interest in hacking that script too...

git clone git://linuxtv.org/media_build.git
cd media_build
git checkout 9d6cebc34b27fea784dec19085970d9b4df9783e

****************************
Updating the building system
****************************
From git://linuxtv.org/media_build
* branch master -> FETCH_HEAD
Updating 9d6cebc..bf38fb5
error: Your local changes to the following files would be overwritten by merge:
build
Please commit your changes or stash them before you merge.
Aborting
make: Entering directory '/kit/media_build/linux'
wget http://linuxtv.org/downloads/drivers/li ... ar.bz2.md5 -O linux-media.tar.bz2.md5.tmp
.....
.....
.....
Applying patches for kernel 4.9.28-v7+
patch -s -f -N -p1 -i ../backports/api_version.patch
patch -s -f -N -p1 -i ../backports/pr_fmt.patch
The text leading up to this was:
--------------------------
|diff --git a/drivers/staging/media/lirc/lirc_sasem.c b/drivers/staging/media/lirc/lirc_sasem.c
|index b0c176e..9b3a85f 100644
|--- a/drivers/staging/media/lirc/lirc_sasem.c
|+++ b/drivers/staging/media/lirc/lirc_sasem.c
--------------------------
No file to patch. Skipping patch.
1 out of 1 hunk ignored
The text leading up to this was:
--------------------------
|diff --git a/drivers/staging/media/lirc/lirc_sir.c b/drivers/staging/media/lirc/lirc_sir.c
|index c75ae43..7646076 100644
|--- a/drivers/staging/media/lirc/lirc_sir.c
|+++ b/drivers/staging/media/lirc/lirc_sir.c
--------------------------
No file to patch. Skipping patch.
1 out of 1 hunk ignored
make[2]: *** [Makefile:138: apply_patches] Error 1
make[2]: Leaving directory '/kit/media_build/linux'
make[1]: *** [Makefile:383: allyesconfig] Error 2
make[1]: Leaving directory '/kit/media_build/v4l'
make: *** [Makefile:26: allyesconfig] Error 2
can't select all drivers at ./build line 490.

justme123 out!
unregistered user

last topic got vandalized & I got banned by an infantile mod

sorry, I have standards

HiassofT
Posts: 221
Joined: Fri Jun 30, 2017 10:07 pm
Location: Salzburg, Austria
Contact: Website

Re: lirc_rpi.c won't compile under latest media_tree & 4.9.2

Sat Jul 01, 2017 8:26 am

gpio-ir-recv depends on rc-core, lirc-dev (CONFIG_LIRC) is an optional feature. While most of the time you'll use in-kernel decoding with the IR drivers from the rc subsystem (via the rc5, rc6, ... decoder modules) you also have the possibility to pass raw, undecoded signals from/to userspace via a /dev/lircX device - CONFIG_LIRC enables this feature.

This feature is mainly useful if your remote uses an odd protocol that's not supported by the in-kernel decoders - you can then use lircd to decode the signals.

Currently the old lirc-only drivers from the staging directory are being converted to rc-core (like eg lirc_serial -> serial_ir), or deleted if they are unmaintained (like eg lirc_parallel). As of kernel 4.12 the only remaining lirc driver is lirc_zilog - eventually this one will be ported over to rc-core as well and the staging/media/lirc directory will be removed.

Concerning kodi:
If you use in-kernel decoding the remote button presses will show up as normal linux input events. As kodi doesn't directly support linux input events the button presses will be handled like standard keyboard input. If you are running X these events pass through the X input layer and only keycodes that are supported in X can be used. Even without X (like eg on LibreELEC) a lot of important keycodes (like KEY_OK, KEY_CHANNELUP, KEY_CHANNELDOWN) don't work as kodi doesn't support these. So, simply speaking, a lot of buttons won't work.

To get all buttons working you can use lircd with the devinput driver. This driver doesn't actually decode raw signals but translates linux input events into lirc events on the lircd socket. See the lirc docs for more info about the devinput driver.

An alternative to lircd in devinput mode is to change the kernel keycode table (via ir-keytable) so it only contains keycodes that are supported by X and kodi (you might need to adapt the kodi keyboard.xml file as well). This may be a little bit more work but you'll also get longpress support in kodi - which isn't supported with lirc events but can be handy for remotes with only a few buttons.

so long,

Hias

Barf
Posts: 8
Joined: Tue Dec 06, 2016 11:42 am

Re: lirc_rpi.c won't compile under latest media_tree & 4.9.2

Sat Jul 01, 2017 9:13 am

@justme123:

So, to the original problem: My gut feeling is that it must be wrong to just nuke set_use_inc/set_use_dec. If so, it would have been dead code in the previous version...

Is IR transmitting (some peoples say, IMHO incorrectly, "blasting") an issue for you?

justme123
Posts: 25
Joined: Tue May 02, 2017 8:13 pm

Re: lirc_rpi.c won't compile under latest media_tree & 4.9.2

Sat Jul 01, 2017 3:56 pm

And the Saga continues ...

@HiassofT
gpio-ir recv looks interesting and maybe the only viable alternative to lirc_rpi.

The code looks like it doesn't need the removed media_tree stuff:
https://github.com/raspberrypi/linux/bl ... -ir-recv.c

And indeed, it depends on rc_core:
modinfo /lib/modules/4.4.50-v7+/kernel/drivers/media/rc/gpio-ir-recv.ko
filename: /lib/modules/4.4.50-v7+/kernel/drivers/media/rc/gpio-ir-recv.ko
license: GPL v2
description: GPIO IR Receiver driver
srcversion: 262F06624D6BEF5E7C68DC4
alias: of:N*T*Cgpio-ir-receiver*
depends: rc-core
vermagic: 4.4.50-v7+ SMP mod_unload modversions ARMv7

The usb DVB adapter that I'm using is fitted with an IR sensor but I couldn't make it work, I got it blacklisted in modprobe.d and went for the GPIO lirc_rpi alternative:
options dvb_usb disable_rc_polling=1 in modprobe.d

As for your suggestions about devinput / lircd / Kodi, I'm using Kodi without X and devinput looks to be a fine solution, although the lircd documentation is far from being something I'd consider complete & accurate. I remember struggling to compile it and make it work properly (especially when not run as root) - I had to search a lot through some other forums / Google. Still, configuring it for devinput might be a solid long term solution.

Thanks again for all your inputs, much appreciate the effort!


@Barf
TBH with you, before I had this issue I wasn't aware that lirc_rpi has also IR transmitting capabilities. Now that I think of it, this could also be considered a security issue - as it could be used to exfil data from a hacked box :)
Personally I don't need any transmitting feature, I'm only using it to control Kodi. If you'd like to modify the code and make it compatible (able to compile) under the new media_tree, just do it!
However, you should consider a long-term approach, as I'm pretty sure that the folks at Raspberry Pi will have issues compiling their own official version with the next Raspbian release - they'll surely use a newer version of media_tree and will fail like me.
Additionally, if it's not taking too much time&effort, you might want to consider adding a module option, a switch just to be able to disable the transmitting capabilities of the module, that's for security freaks like me ;)


@All
Yesterday I've reached out privately to the people at media_tree that committed the changes and briefed them on the actual issue. I got word today from one of them, suggesting that I should just comment the affected lines (references) in lirc_rpi source code. I replied that I had already tried that unsuccessfully and invited them to take a look on this thread.
Last edited by justme123 on Sun Jul 02, 2017 4:44 am, edited 1 time in total.
unregistered user

last topic got vandalized & I got banned by an infantile mod

sorry, I have standards

justme123
Posts: 25
Joined: Tue May 02, 2017 8:13 pm

Re: lirc_rpi.c won't compile under latest media_tree & 4.9.2

Sun Jul 02, 2017 4:40 am

@HiassofT

I've failed to find proper documentation about the gpio-ir-recv driver (actually I couldn't find anything but some examples) and would like to substitute my actual lirc_rpi setup with the gpio-ir-recv while preserving my lircd configuration.

I saw you were also active on the Kodi Forums and I could have asked there for help, but I believe that this is the right place to do it, since lirc_rpi looks like getting EOL pretty soon and there will be other users who would need to do what I'm trying to achieve now.

First, I'm not sure how to call (syntax) gpio-ir-recv in /boot/config.txt and then there might be some changes needed in the lircd conf files too.

Here is my actual configuration:

Kernel/Modules related:

/boot/config.txt:
dtoverlay=lirc-rpi,gpio_in_pin=17,gpio_out_pin=23


lirc related:

______________________
hardware.conf

START_LIRCD=true
START_LIRCMD=false
LOAD_MODULES=false

LIRCD_ARGS="--uinput"
DRIVER="default"
DEVICE="/dev/lirc0"
MODULES="lirc_rpi"

LIRCD_CONF=""
LIRCMD_CONF=""
...etc
______________________

______________________
lirc_options.conf

[lircd]
nodaemon = False
driver = default
device = /dev/lirc0
output = /var/run/lirc/lircd
pidfile = /var/run/lirc/lircd.pid
plugindir = /usr/local/lib/lirc/plugins
permission = 666
allow-simulate = No
repeat-max = 600
... etc
______________________


______________________
lircd.conf

# this config file was automatically generated
# using lirc-0.7.1pre2(any) on Mon Jul 4 22:11:52 2005
#
# contributed by
#
# brand: Technisat
# model no. of remote control: TTS35AI
# devices being controlled by this remote: Skystar 2.6D
#

begin remote

name Technisat_TTS35AI.conf
bits 13
flags RC5|CONST_LENGTH
eps 30
aeps 100

one 882 803
zero 882 803
plead 905
gap 112766
toggle_bit 2


begin codes
KEY_POWER 0x1A8C # Was: Power
KEY_MUTE 0x1A8D # Was: Mute

... etc
______________________


I'd like to ask you, if you're so kind, to guide me / substitute the lirc-rpi with the gpio-ir-recv wherever necessary in the confs above.
I guess I'd be able to amend the lircd related ones on my own, I just published them for orientation.

Thank you in advance!
unregistered user

last topic got vandalized & I got banned by an infantile mod

sorry, I have standards

HiassofT
Posts: 221
Joined: Fri Jun 30, 2017 10:07 pm
Location: Salzburg, Austria
Contact: Website

Re: lirc_rpi.c won't compile under latest media_tree & 4.9.2

Sun Jul 02, 2017 1:29 pm

gpio-ir doesn't have many options, the gpio pin, pull up/down and the default rc-map to use.
Check the overlays README, https://github.com/raspberrypi/linux/bl ... ays/README, the overlay source https://github.com/raspberrypi/linux/bl ... verlay.dts and the devicetree bindings documentation https://github.com/raspberrypi/linux/bl ... ceiver.txt

When compiling yourself make sure you enable all remote controller decoder modules and keymap modules.

The kernel keymaps define the protocol to use and contain scancode to keycode mappings. These are useful so that the kernel can support a large variety of remotes out-of-the box without further (userspace, "ir-keytable") configuration. But usually you'll also install ir-keytable (from the v4l-utils package) to configure the remotes (eg set repeat delay and rate, keycode mappings etc).

For your remote the rc-technisat-usb2 map might be a good start (maybe it's already the correct one and you don't need to configure anything else).

Code: Select all

dtoverlay=gpio-ir,gpio_pin=17,rc-map-name=rc-technisat-usb2
Reboot, run "ir-keytable" and verify that the RC5 protocol is enabled and the rc-technisat-usb2 table is active. Then, to test if the scancodes are received and translated to keycodes correctly run "ir-keytable -t". You should see both scancodes and keycodes. BTW: you can also use "evtest" for testing.

If you get no keycodes at all or wrong mappings you have to create/adapt the keymap. I posted a guide how to do that on the LibreELEC forum - the paths will be different and you can skip the kodi/LibreELEC specific stuff, so just look at the ir-keytable stuff in there https://forum.libreelec.tv/thread/7152- ... #post43745

As for lircd: I'd recommend using the latest lircd version (currently 0.10.0-rc3) as it contains a lot of bugfixes. The version shipping with raspbian is rather old, but should work as well.

Stick to the upstream method of configuring and starting lircd (socket activated systemd service), but you'll want to drop lircd-uinput (this translates lirc events into linux input events). Read the excellent lirc docs for more details (especially the configuration and the technical sections): http://lirc.org/html/index.html

For a quick test start lircd manually, eg with the following command line (adjust the path to devinput.lircd.conf)

Code: Select all

lircd --nodaemon --driver=devinput --device=/dev/input/by-path/platform-ir-receiver-event -o /tmp/lircd.socket devinput.lircd.conf
Then run irw in another shell to see the lirc events when you press buttons:

Code: Select all

irw /tmp/lircd.socket
so long,

Hias

HiassofT
Posts: 221
Joined: Fri Jun 30, 2017 10:07 pm
Location: Salzburg, Austria
Contact: Website

Re: lirc_rpi.c won't compile under latest media_tree & 4.9.2

Sun Jul 02, 2017 4:48 pm

BTW: completely forgot, of course you can also use your existing lircd setup (using /dev/lirc0) as before - just set the rc-map-name to rc-empty then no protocol decoders will be activated.

so long,

Hias

justme123
Posts: 25
Joined: Tue May 02, 2017 8:13 pm

Re: lirc_rpi.c won't compile under latest media_tree & 4.9.2

Mon Jul 03, 2017 12:48 am

@HiassofT

Thanks! I got it working & dropped lirc_rpi for now!

I had some issues with:
dtoverlay=gpio-ir,gpio_pin=17,rc-map-name=rc-technisat-usb2

- first, in the bootlog I got a SegFault as udev launched ir-keytable:

[ 5.427636] rc rc0: gpio_ir_recv as /devices/platform/ir-receiver/rc/rc0
[ 5.471984] lirc_dev: IR Remote Control driver registered, major 244
[ 5.492281] rc rc0: lirc_dev: driver ir-lirc-codec (gpio-rc-recv) registered at minor = 0
[ 5.569198] input: gpio_ir_recv as /devices/platform/ir-receiver/rc/rc0/input0
[ 5.652506] udevd[359]: '/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s rc0' [391] terminated by signal 11 (Segmentation fault)

- afterwards manually running the ir-keytable (without any parameters) I got a good configuration:
ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event0) with:
Driver gpio-rc-recv, table rc-technisat-usb2
Supported protocols: other lirc rc-5 jvc sony nec sanyo mce-kbd rc-6 sharp xmp
Enabled protocols: lirc rc-5
Name: gpio_ir_recv
bus: 25, vendor/product: 0001:0001, version: 0x0100
Repeat delay = 500 ms, repeat period = 125 ms

- lsmod | grep rc
ir_lirc_codec 4792 2
lirc_dev 7455 1 ir_lirc_codec
rc_core 22647 5 lirc_dev,ir_lirc_codec,dvb_usb,gpio_ir_recv

However, lircd was not happy with neither /dev/lirc0 nor /dev/input/by-path/platform-ir-receiver-event (I've tried even the ones reported by ir-keytable).

Then with:
dtoverlay=gpio-ir,gpio_pin=17,rc-map-name=rc-empty
it worked like a charm!

- ir-keytable is still crashing during boot:
[ 5.201710] rc rc0: gpio_ir_recv as /devices/platform/ir-receiver/rc/rc0
[ 5.235281] input: gpio_ir_recv as /devices/platform/ir-receiver/rc/rc0/input0
[ 5.243507] lirc_dev: IR Remote Control driver registered, major 244
[ 5.248382] rc rc0: lirc_dev: driver ir-lirc-codec (gpio-rc-recv) registered at minor = 0
[ 5.369093] udevd[371]: '/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s rc0' [389] terminated by signal 11 (Segmentation fault)
[ 5.653693] bcm2708_i2c 3f804000.i2c: BSC1 Controller at 0x3f804000 (irq 83) (baudrate 100000)

- but its output looks good:
ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event0) with:
Driver gpio-rc-recv, table rc-empty
Supported protocols: other lirc rc-5 jvc sony nec sanyo mce-kbd rc-6 sharp xmp
Enabled protocols: lirc
Name: gpio_ir_recv
bus: 25, vendor/product: 0001:0001, version: 0x0100
Repeat delay = 500 ms, repeat period = 125 ms

Just for the sake of consistence (it has worked also without), I've modified:
/lirc/hardware.conf
comment:
#LIRCD_ARGS="--uinput"
#MODULES="lirc_rpi"
and put instead:
MODULES="gpio_ir_recv"

I' m really happy now and will proceed with the kernel update.
If you know the Webmaster (or anyone else who might have some responsibility) at lirc.org - please tell them to change that horrible background or use a thicker font. :shock:


From my point of view - the issue is resolved.
Thanks again for all your help! (all involved)
unregistered user

last topic got vandalized & I got banned by an infantile mod

sorry, I have standards

Barf
Posts: 8
Joined: Tue Dec 06, 2016 11:42 am

Re: lirc_rpi.c won't compile under latest media_tree & 4.9.2

Wed Jul 05, 2017 7:37 pm

I have done some work on "my" driver, reported in the other thread. Now it works with the new media files. (Thanx to @justme123 for testing it.)

I have no problems retiring lirc_rpi. I did not create it (Aron did...). Lirc is, IMHO, one of the most overrated open source software there is. Just too bad that there is no sending replacement. Preferably it should do hardware PWM and support multiple transmitters (not necessarily independent) (OK, the last two requirements are in conflict...)
... I wasn't aware that lirc_rpi has also IR transmitting capabilities. Now that I think of it, this could also be considered a security issue - as it could be used to exfil data from a hacked box
Where did you get that idea? :?

justme123
Posts: 25
Joined: Tue May 02, 2017 8:13 pm

Re: lirc_rpi.c won't compile under latest media_tree & 4.9.2

Wed Jul 05, 2017 8:15 pm

@Barf

Thanks again for your work and promptitude in adapting the lirc_rpi driver. It is working fine now and able to compile under the new media_tree. Maybe you shouldn't think to retire lirc_rpi, now that you've got it working. I'm sure there are a lot of people still using it and the folks at Raspberry will use your code in their next kernel upgrade (that's if they'll update media_tree and find out that the old code won't compile anymore).

With respect to your question and my concern, I was referring to a module parameter - a switch - to disable its transmitting capabilities. That's if you'd like to use it only as a receiver. There might be security concerns around an interface you cannot control and can be used to exfiltrate data from a hacked box.
However, I was mistakenly considering that an IR Sensor - like the TSOP2238, TSOP2438, *TSOP4838 (I'm also using) is also able to emit. Now I learned that that's not the case and for transmitting data through IR, you'll need some extra gear - components/schematic.

My misunderstanding came from here:

by HiassofT » Fri Jun 30, 2017 10:17 pm
FYI: if you don't need the IR blasting functionality of lirc_rpi I'd recommend using gpio-ir-recv (gpio-ir DT overlay) instead.


by Barf » Sat Jul 01, 2017 9:13 am
@justme123:

So, to the original problem: My gut feeling is that it must be wrong to just nuke set_use_inc/set_use_dec. If so, it would have been dead code in the previous version...

Is IR transmitting (some peoples say, IMHO incorrectly, "blasting") an issue for you?

and:
https://github.com/bengtmartensson/lirc_rpi

Finally, by reading through this more detailed description, I learned that you need special gear to be able to transmit:
http://aron.ws/projects/lirc_rpi/

You shouldn't worry anymore about my security concerns, as they were based on misleading/incomplete information, thus unfounded.

Again, great work, keep it up!
unregistered user

last topic got vandalized & I got banned by an infantile mod

sorry, I have standards

justme123
Posts: 25
Joined: Tue May 02, 2017 8:13 pm

Re: lirc_rpi.c won't compile under latest media_tree & 4.9.2

Wed Jul 05, 2017 9:24 pm

Just for keeping a public record of the test I've done with the new lirc_rpi.c driver from Barf.

Compilation under 4.9.28-v7+ kernel and the latest git cloned media_tree from 06.07.2017
bf38fb5438c3cfd90a7496e951c6902111b77587

- media_build build script output - no warnings/errs on lirc_rpi.o & lirc_rpi.mod.o
Stage 1:
CC [M] /kit/media_build/v4l/ir-sharp-decoder.o
CC [M] /kit/media_build/v4l/ir-mce_kbd-decoder.o
CC [M] /kit/media_build/v4l/ir-lirc-codec.o
CC [M] /kit/media_build/v4l/ir-xmp-decoder.o
CC [M] /kit/media_build/v4l/ati_remote.o
CC [M] /kit/media_build/v4l/ir-hix5hd2.o
CC [M] /kit/media_build/v4l/imon.o
CC [M] /kit/media_build/v4l/lirc_rpi.o
/kit/media_build/v4l/ati_remote.c: In function 'ati_remote_probe':
/kit/media_build/v4l/ati_remote.c:882:4: warning: ' mouse' directive
output may be truncated writing 6 bytes into a region of size between 1
and 80 [-Wformat-truncation=]
"%s mouse", ati_remote->rc_name);
^~~~~~~~~~
/kit/media_build/v4l/ati_remote.c:881:2: note: 'snprintf' output between
7 and 86 bytes into a destination of size 80
snprintf(ati_remote->mouse_name, sizeof(ati_remote->mouse_name),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%s mouse", ati_remote->rc_name);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CC [M] /kit/media_build/v4l/redrat3.o
CC [M] /kit/media_build/v4l/streamzap.o
CC [M] /kit/media_build/v4l/rc-loopback.o


Stage 2:

CC /kit/media_build/v4l/lgdt3306a.mod.o
CC /kit/media_build/v4l/lgdt330x.mod.o
CC /kit/media_build/v4l/lgs8gl5.mod.o
CC /kit/media_build/v4l/lgs8gxx.mod.o
CC /kit/media_build/v4l/lirc_dev.mod.o
CC /kit/media_build/v4l/lirc_rpi.mod.o
CC /kit/media_build/v4l/lm3560.mod.o
CC /kit/media_build/v4l/lm3646.mod.o
CC /kit/media_build/v4l/lnbh25.mod.o
CC /kit/media_build/v4l/lnbp21.mod.o
CC /kit/media_build/v4l/lnbp22.mod.o


make[2]: Leaving directory '/usr/src/linux-headers-4.9.28-v7+'
./scripts/rmmod.pl check
found 570 modules
make[1]: Leaving directory '/kit/media_build/v4l'
**********************************************************
* Compilation finished. Use 'make install' to install them
**********************************************************



- /boot/config.txt lirc_rpi.c related:

dtoverlay=lirc-rpi,gpio_in_pin=17,gpio_out_pin=23


- dmesg - rc related:

[ 4.801178] udevd[363]: starting eudev-3.2.2
[ 5.076807] rc_core: loading out-of-tree module taints kernel.
[ 5.096403] WARNING: You are using an experimental version of the
media stack.
As the driver is backported to an older kernel, it
doesn't offer
enough quality for its usage in production.
Use it with care.
Latest git patches (needed if you report a bug to
linux-media@vger.kernel.org):
2748e76ddb2967c4030171342ebdd3faa6a5e8e8 media: staging:
cxd2099: Activate cxd2099 buffer mode
3e8d8a085ff454527a422aafe9b7dcfa95c09cc5 media: staging:
cxd2099: Removed printing in write_block
6475483734d86f88848fcd61db3d4c35123abcba media: staging:
cxd2099: Removed useless printing in cxd2099 driver
[ 5.209187] lirc_dev: IR Remote Control driver registered, major 243
[ 5.270586] gpiomem-bcm2835 3f200000.gpiomem: Initialised: Registers
at 0x3f200000
[ 5.490836] i2c /dev entries driver
[ 6.300663] lirc_rpi: auto-detected active low receiver on GPIO pin 17
[ 6.313236] lirc_rpi lirc_rpi: lirc_dev: driver lirc_rpi registered
at minor = 0
[ 6.325723] lirc_rpi: driver registered!


- lsmod - rc related
lsmod | grep rc
lirc_rpi 9805 2
lirc_dev 8962 1 lirc_rpi
rc_core 31139 2 dvb_usb,lirc_dev


- info about the lirc-rpi module
modinfo lirc_rpi
filename:
/lib/modules/4.9.28-v7+/kernel/drivers/staging/media/lirc/lirc_rpi.ko
license: GPL
author: Bengt Martensson <barf@bengt-martensson.de>
author: Michael Bishop <cleverca22@gmail.com>
author: Aron Robert Szabo <aron@reon.hu>
description: Infra-red receiver and blaster driver for Raspberry Pi GPIO.
srcversion: 533BB7E5866E52F63B9ACCB
alias: of:N*T*Crpi,lirc-rpiC*
alias: of:N*T*Crpi,lirc-rpi
depends: lirc_dev
vermagic: 4.9.28-v7+ SMP mod_unload modversions ARMv7 p2v8
parm: gpio_out_pin:GPIO output/transmitter pins of the BCM
processor. (default 17) (array of int)
parm: gpio_in_pin:GPIO input pin number of the BCM processor.
(default 18) (int)
parm: gpio_in_pull:GPIO input pin pull configuration. (0 =
off, 1 = up, 2 = down, default down) (int)
parm: sense:Override autodetection of IR receiver circuit (0 =
active high, 1 = active low ) (int)
parm: softcarrier:Software carrier (0 = off, 1 = on, default
on) (bool)
parm: invert:Invert output (0 = off, 1 = on, default off (bool)
parm: debug:Enable debugging messages (bool)



- irw test - compiled and loaded lirc_rpi.c is working without any apparent issues:

irw /var/run/lirc/lircd
0000000000001281 00 KEY_1 Technisat_TTS35AI.conf
0000000000001281 01 KEY_1 Technisat_TTS35AI.conf
0000000000001a82 00 KEY_2 Technisat_TTS35AI.conf
0000000000001a82 01 KEY_2 Technisat_TTS35AI.conf
0000000000001283 00 KEY_3 Technisat_TTS35AI.conf
0000000000001283 01 KEY_3 Technisat_TTS35AI.conf
0000000000001a84 00 KEY_4 Technisat_TTS35AI.conf
0000000000001a84 01 KEY_4 Technisat_TTS35AI.conf
0000000000001285 00 KEY_5 Technisat_TTS35AI.conf
0000000000001a86 00 KEY_6 Technisat_TTS35AI.conf
0000000000001287 00 KEY_7 Technisat_TTS35AI.conf


justme123 out - this time for good! :)
unregistered user

last topic got vandalized & I got banned by an infantile mod

sorry, I have standards

Return to “Device Tree”