lirc-list

New plugin: xboxlibusb (Xbox DVD Movie Playback Kit Dongle)

[Jannik V. <em...@ja...>]

Hey everyone,

I've developed a new libusb plugin for the Dongle of the Xbox DVD Movie
Playback Kit.
I've already put some of my observations at
http://xboxdevwiki.net/Xbox_DVD_Movie_Playback_Kit (which also describes
the hardware and involved IR / USB protocols).

While this receiver is more than 15 years old and isn't sold in stores
anymore, it can be bought very cheaply on places like ebay (mine included
remote and dongle, for less than $5).
As a result people still resort to the old lirc_xbox kernel module for LIRC
0.9, or other weird hacks (such as using an ancient lirc_atiusb, which is a
giant hack).
The motivation for this plugin is that the Xbox remote works out-of-the-box
with the original Dongle which can be connected via a cheap USB adapter
cable (available from China).

At the time of writing, my code can be found here (might move in the
future):



https://github.com/JayFoxRox/lirc-xboxlibusb/tree/xboxlibusb



---

Some design decisions:

- uses pthread instead of `fork()` because I had issues where `SIGTERM`
during `usb_interrupt_read` (as in atilibusb) would break traffic after
connecting `irw` a second time
- uses libusb-1.0 so we can also work around that issue by manually
cancelling a transfer
- recreates the IR payload, which includes the negated data; so this works
with known serial remote configurations[1] (possibly also supports the 360
MCE remotes[2]); I could not confirm the actual IR signal and had to
extrapolate it from LIRC configurations, so this is a bit of a hack
- adds support for 3 known DVD dongles (Gamester / Microsoft / Unknown)
- plugin name matches what you'd expect from older LIRC drivers, although
the Xbox term might also refer to Xbox 360 or Xbox One these days
- the first USB packet is ignored, because it might have been in the buffer
for a very long time
- the USB protocol also tells us how many milliseconds since the last
press, but this information is ignored
- the USB protocol also tells us what appears to be a packet length, but
this information is ignored

Some remaining questions:

- do I have to add any special Makefile magic to handle pthread and
libusb-1.0 correctly (on other platforms)?
- shall I remove or mark the DVD dongles I did not test? (I only own
045E:0284, but assume others to work fine, or with minor changes)
- shall I make the IR payload recreation hack optional? (only would return
8 or 12 data bits, 4 bits are presumably constant start marker)
- what version should I give my plugin?
- what's the best way to have this plugin integrated into upcoming LIRC
releases?

I already did run it through valgrind; so there are no known leaks /
invalid accesses. But probably not catching all edge-cases yet.
There's also a lot of atilibusb stupidity left in the code (which this was
originally based off, until almost a full refactor).
The worst issue is probably that removing the USB device while it's in use,
breaks horribly so you have to restart `lircd` (which is fine for my
use-case, but I'd be willing to fix it, if it was a requirement to get this
plugin upstreamed - although I'm aware of similar crimes in other plugins).
I've also only tested on Arch Linux using `irw`; more test results for
other platforms would be nice.

I might not see all responses because I passionately hate sourceforge and
mailing lists (and therefore don't want to subscribe).
You can also leave feedback on my github repository (although I want to
upstream this plugin, and will read the ml-archive from time to time).

Greetings,
Jannik

[1]
https://sourceforge.net/p/lirc-remotes/code/ci/master/tree/remotes/microsoft/Xbox.lircd.conf
[2]
https://sourceforge.net/p/lirc-remotes/code/ci/master/tree/remotes/microsoft/Xbox_MCE.lircd.conf

problems with LIRC on ubuntu 18,04 arm64

[Richard B. <ri...@g8...>]

Hi
I hope someone on this list can help, I've been using LIRC without
problems on my Hardkernel Odroid C2 SBC with ubuntu16.04
But the move to ubuntu18.04, which changed the directory structure and
functionality, now it just wont start.
Whereas before lircd could be started with "sudo service start lircd",
that now results in not being able to write to files in /var
So it looks as if the use of service has been fully replaced by
systemctl., verified on other applications that can no longer write to
/var

starting lircd with "sudo systemctl start lircd"   does allow writing
to /var
but

"sudo systemctl status lircd" shows this:-
odroid@odroid:~$ sudo systemctl start lircd
odroid@odroid:~$ sudo systemctl status lircd
● lircd.service - Flexible IR remote input/output application support
   Loaded: loaded (/lib/systemd/system/lircd.service; enabled; vendor
preset: enabled)
   Active: failed (Result: signal) since Tue 2018-09-11 10:38:07 UTC;
14s ago
     Docs: man:lircd(8)
           http://lirc.org/html/configure.html
  Process: 3858 ExecStart=/usr/sbin/lircd --nodaemon (code=killed,
signal=SEGV)
 Main PID: 3858 (code=killed, signal=SEGV)

Sep 11 10:38:07 odroid systemd[1]: Started Flexible IR remote\
input/output application support.
Sep 11 10:38:07 odroid lircd[3858]: ciniparser: input line too long in\
/etc/lirc/lirc_options.conf (30)
Sep 11 10:38:07 odroid lircd-0.10.0[3858]: Info: lircd:  Opening log,\
level: Info
Sep 11 10:38:07 odroid lircd-0.10.0[3858]: Notice: Version: lircd\
0.10.0
Sep 11 10:38:07 odroid lircd-0.10.0[3858]: Notice: System info: Linux\
odroid 3.16.57-25 #1 SMP PREEMPT Mon Jul 30 19:27:38 -03 2018 aarch64\
aarch6
Sep 11 10:38:07 odroid systemd[1]: lircd.service: Main process exited,\
code=killed, status=11/SEGV
Sep 11 10:38:07 odroid systemd[1]: lircd.service: Failed with result\
'signal'.

Sorry about the line wrapping

Ciniparser complains about the last line in the lirc_options.conf file
even if you put a hash at the start of the line !

lirc_options.conf  file :-

[lircd]
nodaemon        = False
driver          = default
device          = /dev/lirc0
output          = /var/run/lirc/lircd
pidfile         = /var/run/lirc/lircd.pid
plugindir       = /usr/lib/aarch64-linux-gnu/lirc/plugins
permission      = 666
allow-simulate  = No
repeat-max      = 600
#effective-user =
#listen         = [address:]port
#connect        = host[:port]
#loglevel       = 6
#release        = true
#release_suffix = _EVUP
#logfile        = ...
#driver-options = ...
 
[lircmd]
uinput          = False
nodaemon        = False
 
[modinit]
code = /sbin/modprobe meson-ir
 
[lircd-uinput]
add-release-events = True
release-timeout    = 50
release-suffix     = _EVUP

The modules do load OK.

I suspect all the hard work you guys put is , has been undone by
ubuntu18.04.
Any help greatly appreciated
-- 
 Best wishes /73 
 Richard Bown
 
 Email : ri...@g8...

 HTTP  :  http://www.g8jvm.com
 
 ######################################################################

 Ham Call: G8JVM . QRV: 50-432 MHz + Microwave 
 Maidenhead QRA: IO82SP38, LAT. 52 39.720' N LONG. 2 28.171 W
 QRV 6mtrs 200W, 4mtrs 150W, 2mtrs 300W, 70cms 200W, 
 Microwave 1296MHz 140W, 2320MHz 100W & 10368MHz 5W
 OS: Linux Mint 19 x86_64 Tara, on a Dell Inspiron N5030 laptop
 ######################################################################

Re: Comcast/Xfinity X1 / XR11 unsuccessful...

[VDR U. <use...@gm...>]

> The only component I can't get to react to LIRC is my x1 (XR11 remote) cable
> box.

Are you sure you've got the version of that remote that supports IR,
and isn't RF-only?

Re: Comcast/Xfinity X1 / XR11 unsuccessful...

[Jan C. <jan...@gm...>]

On 30/08/18 14:30, Robert H wrote:
> Hello there....first post here....
> 
> started using LIRC a few weeks ago. 
> 
> The only component I can't get to react to LIRC is my x1 (XR11 remote)
> cable box.
> 
> I've tried recording from my main remote (IR turned on) and from my
> logitech 650 both to no avail.
> 
> Wondering what I'm missing or if anyone has the conf file. 

I recommend using IRScrutinizer [1] to capture the IR signals from the
original remote (ideally using an Arduino [2]) and having it generate a
LIRC file.

[1] http://www.harctoolbox.org/IrScrutinizer.html
[2] http://www.harctoolbox.org/arduino_nano.html