On Mon, Dec 21, 2015 at 02:12:41PM +0100, Patrik Lundin wrote: > > Currently it is only attached as an ugen device: > === > ugen0 at uhub1 port 2 "Telldus TellStick Duo" rev 2.00/6.00 addr 2 > === > > The diff below makes it attach as an uftdi device: > === > uftdi0 at uhub2 port 1 configuration 1 interface 0 "Telldus TellStick Duo" > rev 2.00/6.00 addr 2 > ucom0 at uftdi0 portno 1 > === >
Hmm, so this was interesting... After getting the rfcmd tool to work I moved forward with using the replacement telldus-core software instead, which has a deamon called telldusd. After struggling for a while trying to get telldusd to work I rolled back to the previous kernel, and suddenly telldusd started working. I can see that it has opened a bunch of ugen devices: === # fstat -p 17591 USER CMD PID FD MOUNT INUM MODE R/W SZ|DV root telldusd 17591 text /usr/local 1013387 -r-xr-xr-x r 440042 root telldusd 17591 wd / 2 drwxr-xr-x r 512 root telldusd 17591 0* unix stream 0xffff8000002ec180 root telldusd 17591 1 pipe 0xffffff011fd2be10 state: root telldusd 17591 2 pipe 0xffffff011fd2be10 state: root telldusd 17591 3 / 865 crw-rw---- rw ugen0.00 root telldusd 17591 4 pipe 0xffffff011fd2b9d8 state: root telldusd 17591 5 pipe 0xffffff011fd2b9d8 state: root telldusd 17591 6* unix stream 0xffff8000002b9d80 root telldusd 17591 7 / 867 crw-rw---- w ugen0.02 root telldusd 17591 8 / 866 crw-rw---- r ugen0.01 root telldusd 17591 9* unix stream 0xffff800000355880 === This was pretty discouraging: it appears the supported program works better when the kernel knows less about the device. It uses libftdi, which I guess is supposed to contact the generic device directly. Any input on how this should be managed? Currently I feel stuck between a rock and a hard place :). -- Patrik Lundin
