From: Alexander P. <ao...@ya...> - 2008-06-01 20:06:49
|
Hi, Daniel, All, I have published the very first version of the IMON driver for FreeBSD. You can find it here: http://www.xs4all.nl/~aopopov/imon/imon.html Please note that this is still work in progress; I would definitely appreciate any help in testing & feedback. Regards, Alexander. ----- Original Message ---- From: Daniel Rich <dr...@em...> To: alexx8 <ao...@ya...> Cc: lir...@li... Sent: Wednesday, May 21, 2008 8:27:04 PM Subject: Re: LIRC on FreeBSD with a USB imon Wow, that's great news! I had been considering looking at porting the driver over, but since I haven't done any driver work in something like 20 years (and that was System V/386 streams drivers), I was hoping that someone else had beat me to it. :) If you need someone to do more testing once you have it stable, let me know. I'm not going to have any time to play with it until after the first of June, but I would love to give it a try after that. Thanks again for the reply. alexx8 wrote: Hi, Dan, It's not that easy. ugen is just an universal USB driver that gets attached to a device if no better matching driver is found. Getting imon to work with ugen would be quite some effort... Anyway, I have been developing (porting) linux imon driver to FreeBSD in my spare time (not much unfortunately), and I am going to publish it in the coming weeks. But you can already see how it looks like on my Silversone case running FreeBSD 7.0: http://www.xs4all.nl/~aopopov/imon/imon.html Regards, Alex. Dan Rich wrote: I've decided to take another stab at getting my imon IR interface working on my FreeBSD server. Unfortunately, it looks like there aren't any kernel-level drivers for the imon (or any other lirc interfaces), however it does show up as /dev/ugen1.1. I can cat the device and I see data being received. For example running od -x against /dev/ugen1, I normally see "ffff ffff ffff ff2e", and when I press the mute key on the remote I see "952b b795 0000 012e". This seems to be close to what I would expect from the imon lirc.conf file I am trying to use, the imon_pad mute should send 0x2b9595b7. However, lircd doesn't seem to like this, the log file contains: lircd: Really read 2 bytes from '/dev/ugen1.1', expected 3 Does anyone have any suggestions on where I can go from here? Are the special flags I need to convince lircd that it is connected to a usb serial device? Am I out of luck unless I break down and write a device drive (ick)? Thanks! -- Dan Rich <dr...@em...> | http://www.employees.org/~drich/ | "Step up to red alert!" "Are you sure, sir? | It means changing the bulb in the sign..." | - Red Dwarf (BBC) ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- Dan Rich <dr...@em...> | http://www.employees.org/~drich/ | "Step up to red alert!" "Are you sure, sir? | It means changing the bulb in the sign..." | - Red Dwarf (BBC) |
From: Alexander P. <ao...@ya...> - 2008-06-05 18:45:19
|
Hi, Daniel, Sure there will be joy in mudville :-) From the debug info I see that you have exactly the same imon model as I; so it should work. The fact that it correctly detects the device and creates nodes under /dev, already indicates that at least half of the driver works. There are a few things that might help you: 1. there is a bug in my driver that prevents you from stopping LIRC daemon; so if you're testing, better remove lircd.sh from /usr/local/etc/rc.d and reboot. 2. The driver is not reentrant, i.e. if one client, say LIRCd opens /dev/lirc0, then running my test script ir_test.pl will simply fail. I suggest to start with small - just install the driver (that you already did), then, without starting LIRCd or LCDProc, run lcd_test.pl to test VFD. This script alone should print text into the display. If not, look what the driver has printed into the console: there are a lot of debugging information, and you should see /dev/lcd0 being open, and then text written to it. The same holds for ir_test.pl. What it does is simply opens /dev/lirc0 and then waits for user input. Do not press enter, but rather start pressing buttons on your remote. You should see button codes coming from the driver into the console. Let me know how it goes, I am sure we can get it working. Regards, Alexander. ----- Original Message ---- From: Daniel Rich <dr...@em...> To: Alexander Popov <ao...@ya...> Cc: lir...@li... Sent: Thursday, June 5, 2008 3:37:36 AM Subject: Re: LIRC on FreeBSD with a USB imon No joy in mudville. If I don't load the driver I can still see data coming from the ugen interface, but I don't get anything from /dev/lirc0 with the driver loaded using the test code or the patched lircd. It does see the device, and it created /dev/lirc0 and /dev/lcd0. Any thoughts on debugging? Here is what I see from the driver with debug enabled on boot: imon: USB_MATCH() - enter imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: checking idVendor = 0x463, idProduct = 0xffff imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: checking idVendor = 0x7b8, idProduct = 0xb02a imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: checking idVendor = 0x46d, idProduct = 0xc505 imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: checking idVendor = 0x46d, idProduct = 0xc505 imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: checking idVendor = 0x15c2, idProduct = 0xffdc imon: found a match, idVendor = 0x15c2, idProduct = 0xffdc imon: USB_MATCH() - exit: ffffffec imon: USB_MATCH() - enter imon: checking idVendor = 0x15c2, idProduct = 0xffdc imon: found a match, idVendor = 0x15c2, idProduct = 0xffdc imon: USB_MATCH() - exit: ffffffec imon0: <vendor 0x15c2 product 0xffdc, class 0/0, rev 1.10/0.00, addr 3> on uhub0 imon: USB_ATTACH(device: imon0) - enter imon: device supports 1 interfaces imon: device supports 2 endpoints imon: filter(): found endpoint nr 0 imon: filter(): using endpoint 0 (addr: 0x81) for IR output imon: filter(): found endpoint nr 1 imon: filter(): using endpoint 1 (addr: 0x2) for VFD input imon: VFD requires 6th packet: 1 imon: IR signals decoded onboard: 1 imon: successfully created device node for IR imon: successfully created device node for VFD imon: USB_ATTACH() - exit: 0 And from usbdevs -v: Controller /dev/usb0: addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), nVidia(0x0000), rev 1.00 port 1 powered port 2 powered port 3 addr 2: low speed, power 98 mA, config 1, USB Receiver(0xc505), Logitech(0x046d), rev 17.00 port 4 powered port 5 powered port 6 addr 3: low speed, power 100 mA, config 1, product 0xffdc(0xffdc), vendor 0x15c2(0x15c2), rev 0.00 port 7 powered port 8 powered Controller /dev/usb1: addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), nVidia(0x0000), rev 1.00 port 1 powered port 2 addr 2: high speed, self powered, config 1, USB2.0 Hub(0x0606), vendor 0x05e3(0x05e3), rev 7.02 port 1 addr 3: low speed, power 20 mA, config 1, ellipse(0xffff), MGE UPS SYSTEMS(0x0463), rev 0.01 port 2 addr 4: full speed, self powered, config 1, Standard USB Hub(0x3301), vendor 0x03eb(0x03eb), rev 3.00 port 1 addr 5: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 port 2 addr 6: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 port 3 addr 7: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 port 4 addr 8: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 port 3 powered port 4 addr 9: full speed, power 86 mA, config 1, Bluetooth USB Adapter(0xb02a), vendor 0x07b8(0x07b8), rev 5.25 port 3 powered port 4 powered port 5 powered port 6 powered port 7 powered port 8 powered Daniel Rich wrote: > Woo hoo!!! I'll pull this down and give it at try tonight. I need to > pull the server down for a bit anyway, I just got the SPDIF interface > for my motherboard, I want to see if that plays better with my stereo > as well. > > Thanks, and I'll let you know how it goes. > > Alexander Popov wrote: >> Hi, Daniel, All, >> >> I have published the very first version of the IMON driver for >> FreeBSD. You can find it here: >> http://www.xs4all.nl/~aopopov/imon/imon.html >> Please note that this is still work in progress; I would definitely >> appreciate any help in testing & feedback. >> >> Regards, >> >> Alexander. >> >> ----- Original Message ---- >> From: Daniel Rich <dr...@em...> >> To: alexx8 <ao...@ya...> >> Cc: lir...@li... >> Sent: Wednesday, May 21, 2008 8:27:04 PM >> Subject: Re: LIRC on FreeBSD with a USB imon >> >> Wow, that's great news! I had been considering looking at porting >> the driver over, but since I haven't done any driver work in >> something like 20 years (and that was System V/386 streams drivers), >> I was hoping that someone else had beat me to it. :) >> >> If you need someone to do more testing once you have it stable, let >> me know. I'm not going to have any time to play with it until after >> the first of June, but I would love to give it a try after that. >> >> Thanks again for the reply. >> >> alexx8 wrote: >>> Hi, Dan, >>> >>> It's not that easy. ugen is just an universal USB driver that gets attached >>> to a device if no better matching driver is found. Getting imon to work with >>> ugen would be quite some effort... >>> Anyway, I have been developing (porting) linux imon driver to FreeBSD in my >>> spare time (not much unfortunately), and I am going to publish it in the >>> coming weeks. But you can already see how it looks like on my Silversone >>> case running FreeBSD 7.0: http://www.xs4all.nl/~aopopov/imon/imon.html >>> >>> Regards, >>> >>> Alex. >>> >>> >>> Dan Rich wrote: >>> >>>> I've decided to take another stab at getting my imon IR interface >>>> working on my FreeBSD server. Unfortunately, it looks like there aren't >>>> any kernel-level drivers for the imon (or any other lirc interfaces), >>>> however it does show up as /dev/ugen1.1. I can cat the device and I see >>>> data being received. For example running od -x against /dev/ugen1, I >>>> normally see "ffff ffff ffff ff2e", and when I press the mute key on the >>>> remote I see "952b b795 0000 012e". This seems to be close to what I >>>> would expect from the imon lirc.conf file I am trying to use, the >>>> imon_pad mute should send 0x2b9595b7. However, lircd doesn't seem to >>>> like this, the log file contains: lircd: Really read 2 bytes from >>>> '/dev/ugen1.1', expected 3 >>>> >>>> Does anyone have any suggestions on where I can go from here? Are the >>>> special flags I need to convince lircd that it is connected to a usb >>>> serial device? Am I out of luck unless I break down >>>> and write a device >>>> drive (ick)? >>>> >>>> Thanks! >>>> >>>> -- Dan Rich <dr...@em...> | http://www.employees.org/~drich/ | "Step up to red alert!" "Are you sure, sir? | It means changing the bulb in the sign..." | - Red Dwarf (BBC) |
From: Daniel R. <dr...@em...> - 2008-06-05 21:01:20
|
That's basically where I'm at right now, I just brought up lircd and LCDd to see if they could talk to the devices. I rebooted last night with just the driver loaded and both of those disabled, still no luck. Your debugging ideas are exactly what I tried. I just tried running the lcd test (with one modification btw, I added a ' or die "cannot open /dev/lcd0: $!"' to the open statement), and no dice. Running a truss of it I see: open("/dev/lcd0",O_WRONLY|O_CREAT|O_TRUNC,0666) = 3 (0x3) fstat(3,{mode=crw-r--r-- ,inode=114,size=0,blksize=4096}) = 0 (0x0) fcntl(3,F_SETFD,FD_CLOEXEC) = 0 (0x0) getdtablesize(0x1130,0xbfbfe890,0xbfbfe978,0x881789e4,0x0,0xbfbfe890) = 11095 (0x2b57) fcntl(3,F_GETFL,) = 1 (0x1) fstat(3,{mode=crw-r--r-- ,inode=114,size=0,blksize=4096}) = 0 (0x0) ioctl(3,TIOCGETA,0xbfbfe920) = 0 (0x0) fcntl(0,F_SETFD,0x0) = 0 (0x0) fstat(0,{mode=crw--w---- ,inode=210,size=0,blksize=4096}) = 0 (0x0) break(0x8068000) = 0 (0x0) ioctl(0,TIOCGETA,0xbfbfc860) = 0 (0x0) write(3," Powered by FreeBSD!",28) ERR#5 'Input/output error' and dmesg tells me: imon: imonopen(u: 0, e: 0) - enter imon: successfully opened a pipe to VFD imon: imonopen(u: 0, e: 0) - exit: 0 (1) imon: imonioctl(u: 0, e: 0, cmd: 402c7413) - enter imon: ioctl is only implemented for IR - exit imon: imonwrite(u: 0, e: 0) - enter imon: vfd_transfer(device: imon0) - enter imon: transferred 0 bytes imon: transfer has failed imon: vfd_transfer() - exit imon: imonwrite(u: 0, e: 0) - exit: 5 imon: imonclose(u: 0, e: 0) - enter imon: user processes have all gone imon: imonclose(u: 0, e: 0) - exit: 0 (0) The good news is that I'm seeing data from the IR port at the moment. The bad news is that I'm not at home, so it's hard to press buttons on the remote remotely. :) Dmesg says: imon: imonopen(u: 0, e: 1) - enter imon: successfully opened a pipe to IR imon: imonopen(u: 0, e: 1) - exit: 0 (1) imon: imonintr() - data = bf ff ff ff 00 00 2e 01 imon: imonintr() - data = 7f ff ff ff 00 00 2e 01 imon: imonintr() - data = ef ff ff ff 00 00 2e 01 imon: imonclose(u: 0, e: 1) - enter imon: imonintr() - status = cancelled imon: user processes have all gone imon: imonclose(u: 0, e: 1) - exit: 0 (0) I'll have to do some more testing when I get home tonight. I may even dig around in the driver code a bit if I get some time (ick :) ). Thanks again for working on this! Alexander Popov wrote: > Hi, Daniel, > > Sure there will be joy in mudville :-) From the debug info I see that you have exactly the same imon model as I; so it should work. The fact that it correctly detects the device and creates nodes under > /dev, already indicates that at least half of the driver works. > > There are a few things that might help you: > > 1. there is a bug in my driver that prevents you from stopping LIRC daemon; so if you're testing, better remove lircd.sh from /usr/local/etc/rc.d and reboot. > 2. The driver is not reentrant, i.e. if one client, say LIRCd opens /dev/lirc0, then running my test script ir_test.pl will simply fail. > > I suggest to start with small - just install the driver (that you already did), then, without starting LIRCd or LCDProc, run lcd_test.pl to test VFD. This script alone should print text into the display. If not, look what the driver has printed into the console: there are a lot of debugging information, and you should see /dev/lcd0 being open, and then text written to it. > The same holds for ir_test.pl. What it does is simply opens /dev/lirc0 and then waits for user input. Do not press enter, but rather start pressing buttons on your remote. You should see button codes coming from the driver into the console. > > Let me know how it goes, I am sure we can get it working. > > Regards, > > Alexander. > > > ----- Original Message ---- > From: Daniel Rich <dr...@em...> > To: Alexander Popov <ao...@ya...> > Cc: lir...@li... > Sent: Thursday, June 5, 2008 3:37:36 AM > Subject: Re: LIRC on FreeBSD with a USB imon > > No joy in mudville. If I don't load the driver I can still see data > coming from the ugen interface, but I don't get anything from /dev/lirc0 > with the driver loaded using the test code or the patched lircd. It > does see the device, and it created /dev/lirc0 and /dev/lcd0. > > Any thoughts on debugging? Here is what I see from the driver with > debug enabled on boot: > > imon: USB_MATCH() - enter > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: checking idVendor = 0x463, idProduct = 0xffff > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: checking idVendor = 0x7b8, idProduct = 0xb02a > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: checking idVendor = 0x46d, idProduct = 0xc505 > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: checking idVendor = 0x46d, idProduct = 0xc505 > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: checking idVendor = 0x15c2, idProduct = 0xffdc > imon: found a match, idVendor = 0x15c2, idProduct = 0xffdc > imon: USB_MATCH() - exit: ffffffec > imon: USB_MATCH() - enter > imon: checking idVendor = 0x15c2, idProduct = 0xffdc > imon: found a match, idVendor = 0x15c2, idProduct = 0xffdc > imon: USB_MATCH() - exit: ffffffec > imon0: <vendor 0x15c2 product 0xffdc, class 0/0, rev 1.10/0.00, addr 3> on uhub0 > imon: USB_ATTACH(device: imon0) - enter > imon: device supports 1 interfaces > imon: device supports 2 endpoints > imon: filter(): found endpoint nr 0 > imon: filter(): using endpoint 0 (addr: 0x81) for IR output > imon: filter(): found endpoint nr 1 > imon: filter(): using endpoint 1 (addr: 0x2) for VFD input > imon: VFD requires 6th packet: 1 > imon: IR signals decoded onboard: 1 > imon: successfully created device node for IR > imon: successfully created device node for VFD > imon: USB_ATTACH() - exit: 0 > > > And from usbdevs -v: > > Controller /dev/usb0: > addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), nVidia(0x0000), rev 1.00 > port 1 powered > port 2 powered > port 3 addr 2: low speed, power 98 mA, config 1, USB Receiver(0xc505), Logitech(0x046d), rev 17.00 > port 4 powered > port 5 powered > port 6 addr 3: low speed, power 100 mA, config 1, product 0xffdc(0xffdc), vendor 0x15c2(0x15c2), rev 0.00 > port 7 powered > port 8 powered > Controller /dev/usb1: > addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), nVidia(0x0000), rev 1.00 > port 1 powered > port 2 addr 2: high speed, self powered, config 1, USB2.0 Hub(0x0606), vendor 0x05e3(0x05e3), rev 7.02 > port 1 addr 3: low speed, power 20 mA, config 1, ellipse(0xffff), MGE UPS SYSTEMS(0x0463), rev 0.01 > port 2 addr 4: full speed, self powered, config 1, Standard USB Hub(0x3301), vendor 0x03eb(0x03eb), rev 3.00 > port 1 addr 5: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 > port 2 addr 6: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 > port 3 addr 7: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 > port 4 addr 8: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 > port 3 powered > port 4 addr 9: full speed, power 86 mA, config 1, Bluetooth USB Adapter(0xb02a), vendor 0x07b8(0x07b8), rev 5.25 > port 3 powered > port 4 powered > port 5 powered > port 6 powered > port 7 powered > port 8 powered > > > > > Daniel Rich wrote: > >> Woo hoo!!! I'll pull this down and give it at try tonight. I need to >> pull the server down for a bit anyway, I just got the SPDIF interface >> for my motherboard, I want to see if that plays better with my stereo >> as well. >> >> Thanks, and I'll let you know how it goes. >> >> Alexander Popov wrote: >> >>> Hi, Daniel, All, >>> >>> I have published the very first version of the IMON driver for >>> FreeBSD. You can find it here: >>> http://www.xs4all.nl/~aopopov/imon/imon.html >>> Please note that this is still work in progress; I would definitely >>> appreciate any help in testing & feedback. >>> >>> Regards, >>> >>> Alexander. >>> >>> ----- Original Message ---- >>> From: Daniel Rich <dr...@em...> >>> To: alexx8 <ao...@ya...> >>> Cc: lir...@li... >>> Sent: Wednesday, May 21, 2008 8:27:04 PM >>> Subject: Re: LIRC on FreeBSD with a USB imon >>> >>> Wow, that's great news! I had been considering looking at porting >>> the driver over, but since I haven't done any driver work in >>> something like 20 years (and that was System V/386 streams drivers), >>> I was hoping that someone else had beat me to it. :) >>> >>> If you need someone to do more testing once you have it stable, let >>> me know. I'm not going to have any time to play with it until after >>> the first of June, but I would love to give it a try after that. >>> >>> Thanks again for the reply. >>> >>> alexx8 wrote: >>> >>>> Hi, Dan, >>>> >>>> It's not that easy. ugen is just an universal USB driver that gets attached >>>> to a device if no better matching driver is found. Getting imon to work with >>>> ugen would be quite some effort... >>>> Anyway, I have been developing (porting) linux imon driver to FreeBSD in my >>>> spare time (not much unfortunately), and I am going to publish it in the >>>> coming weeks. But you can already see how it looks like on my Silversone >>>> case running FreeBSD 7.0: http://www.xs4all.nl/~aopopov/imon/imon.html >>>> >>>> Regards, >>>> >>>> Alex. >>>> >>>> >>>> Dan Rich wrote: >>>> >>>> >>>>> I've decided to take another stab at getting my imon IR interface >>>>> working on my FreeBSD server. Unfortunately, it looks like there aren't >>>>> any kernel-level drivers for the imon (or any other lirc interfaces), >>>>> however it does show up as /dev/ugen1.1. I can cat the device and I see >>>>> data being received. For example running od -x against /dev/ugen1, I >>>>> normally see "ffff ffff ffff ff2e", and when I press the mute key on the >>>>> remote I see "952b b795 0000 012e". This seems to be close to what I >>>>> would expect from the imon lirc.conf file I am trying to use, the >>>>> imon_pad mute should send 0x2b9595b7. However, lircd doesn't seem to >>>>> like this, the log file contains: lircd: Really read 2 bytes from >>>>> '/dev/ugen1.1', expected 3 >>>>> >>>>> Does anyone have any suggestions on where I can go from here? Are the >>>>> special flags I need to convince lircd that it is connected to a usb >>>>> serial device? Am I out of luck unless I break down >>>>> and write a device >>>>> drive (ick)? >>>>> >>>>> Thanks! >>>>> >>>>> >>>>> > > > -- Dan Rich <dr...@em...> | http://www.employees.org/~drich/ | "Step up to red alert!" "Are you sure, sir? | It means changing the bulb in the sign..." | - Red Dwarf (BBC) |
From: Alexander P. <ao...@ya...> - 2008-06-05 21:39:58
|
Hi, Daniel, The fact that you see imon: imonintr() - data = bf ff ff ff 00 00 2e 01, etc. means IR part of the driver is working fine. I am sure that LIRC will work too, just check if you correctly followed my installation instructions. However, the fact that you see imon: transferred 0 bytes and imon: transfer has failed, is troubling... maybe there is something with wiring? Regards, Alexander. ----- Original Message ---- From: Daniel Rich <dr...@em...> To: Alexander Popov <ao...@ya...> Cc: lir...@li... Sent: Thursday, June 5, 2008 11:00:58 PM Subject: Re: LIRC on FreeBSD with a USB imon That's basically where I'm at right now, I just brought up lircd and LCDd to see if they could talk to the devices. I rebooted last night with just the driver loaded and both of those disabled, still no luck. Your debugging ideas are exactly what I tried. I just tried running the lcd test (with one modification btw, I added a ' or die "cannot open /dev/lcd0: $!"' to the open statement), and no dice. Running a truss of it I see: open("/dev/lcd0",O_WRONLY|O_CREAT|O_TRUNC,0666) = 3 (0x3) fstat(3,{mode=crw-r--r-- ,inode=114,size=0,blksize=4096}) = 0 (0x0) fcntl(3,F_SETFD,FD_CLOEXEC) = 0 (0x0) getdtablesize(0x1130,0xbfbfe890,0xbfbfe978,0x881789e4,0x0,0xbfbfe890) = 11095 (0x2b57) fcntl(3,F_GETFL,) = 1 (0x1) fstat(3,{mode=crw-r--r-- ,inode=114,size=0,blksize=4096}) = 0 (0x0) ioctl(3,TIOCGETA,0xbfbfe920) = 0 (0x0) fcntl(0,F_SETFD,0x0) = 0 (0x0) fstat(0,{mode=crw--w---- ,inode=210,size=0,blksize=4096}) = 0 (0x0) break(0x8068000) = 0 (0x0) ioctl(0,TIOCGETA,0xbfbfc860) = 0 (0x0) write(3," Powered by FreeBSD!",28) ERR#5 'Input/output error' and dmesg tells me: imon: imonopen(u: 0, e: 0) - enter imon: successfully opened a pipe to VFD imon: imonopen(u: 0, e: 0) - exit: 0 (1) imon: imonioctl(u: 0, e: 0, cmd: 402c7413) - enter imon: ioctl is only implemented for IR - exit imon: imonwrite(u: 0, e: 0) - enter imon: vfd_transfer(device: imon0) - enter imon: transferred 0 bytes imon: transfer has failed imon: vfd_transfer() - exit imon: imonwrite(u: 0, e: 0) - exit: 5 imon: imonclose(u: 0, e: 0) - enter imon: user processes have all gone imon: imonclose(u: 0, e: 0) - exit: 0 (0) The good news is that I'm seeing data from the IR port at the moment. The bad news is that I'm not at home, so it's hard to press buttons on the remote remotely. :) Dmesg says: imon: imonopen(u: 0, e: 1) - enter imon: successfully opened a pipe to IR imon: imonopen(u: 0, e: 1) - exit: 0 (1) imon: imonintr() - data = bf ff ff ff 00 00 2e 01 imon: imonintr() - data = 7f ff ff ff 00 00 2e 01 imon: imonintr() - data = ef ff ff ff 00 00 2e 01 imon: imonclose(u: 0, e: 1) - enter imon: imonintr() - status = cancelled imon: user processes have all gone imon: imonclose(u: 0, e: 1) - exit: 0 (0) I'll have to do some more testing when I get home tonight. I may even dig around in the driver code a bit if I get some time (ick :) ). Thanks again for working on this! Alexander Popov wrote: > Hi, Daniel, > > Sure there will be joy in mudville :-) From the debug info I see that you have exactly the same imon model as I; so it should work. The fact that it correctly detects the device and creates nodes under > /dev, already indicates that at least half of the driver works. > > There are a few things that might help you: > > 1. there is a bug in my driver that prevents you from stopping LIRC daemon; so if you're testing, better remove lircd.sh from /usr/local/etc/rc.d and reboot. > 2. The driver is not reentrant, i.e. if one client, say LIRCd opens /dev/lirc0, then running my test script ir_test.pl will simply fail. > > I suggest to start with small - just install the driver (that you already did), then, without starting LIRCd or LCDProc, run lcd_test.pl to test VFD. This script alone should print text into the display. If not, look what the driver has printed into the console: there are a lot of debugging information, and you should see /dev/lcd0 being open, and then text written to it. > The same holds for ir_test.pl. What it does is simply opens /dev/lirc0 and then waits for user input. Do not press enter, but rather start pressing buttons on your remote. You should see button codes coming from the driver into the console. > > Let me know how it goes, I am sure we can get it working. > > Regards, > > Alexander. > > > ----- Original Message ---- > From: Daniel Rich <dr...@em...> > To: Alexander Popov <ao...@ya...> > Cc: lir...@li... > Sent: Thursday, June 5, 2008 3:37:36 AM > Subject: Re: LIRC on FreeBSD with a USB imon > > No joy in mudville. If I don't load the driver I can still see data > coming from the ugen interface, but I don't get anything from /dev/lirc0 > with the driver loaded using the test code or the patched lircd. It > does see the device, and it created /dev/lirc0 and /dev/lcd0. > > Any thoughts on debugging? Here is what I see from the driver with > debug enabled on boot: > > imon: USB_MATCH() - enter > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: checking idVendor = 0x463, idProduct = 0xffff > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: checking idVendor = 0x7b8, idProduct = 0xb02a > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: checking idVendor = 0x46d, idProduct = 0xc505 > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: checking idVendor = 0x46d, idProduct = 0xc505 > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: USB_MATCH() - exit: 6 > imon: USB_MATCH() - enter > imon: checking idVendor = 0x15c2, idProduct = 0xffdc > imon: found a match, idVendor = 0x15c2, idProduct = 0xffdc > imon: USB_MATCH() - exit: ffffffec > imon: USB_MATCH() - enter > imon: checking idVendor = 0x15c2, idProduct = 0xffdc > imon: found a match, idVendor = 0x15c2, idProduct = 0xffdc > imon: USB_MATCH() - exit: ffffffec > imon0: <vendor 0x15c2 product 0xffdc, class 0/0, rev 1.10/0.00, addr 3> on uhub0 > imon: USB_ATTACH(device: imon0) - enter > imon: device supports 1 interfaces > imon: device supports 2 endpoints > imon: filter(): found endpoint nr 0 > imon: filter(): using endpoint 0 (addr: 0x81) for IR output > imon: filter(): found endpoint nr 1 > imon: filter(): using endpoint 1 (addr: 0x2) for VFD input > imon: VFD requires 6th packet: 1 > imon: IR signals decoded onboard: 1 > imon: successfully created device node for IR > imon: successfully created device node for VFD > imon: USB_ATTACH() - exit: 0 > > > And from usbdevs -v: > > Controller /dev/usb0: > addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), nVidia(0x0000), rev 1.00 > port 1 powered > port 2 powered > port 3 addr 2: low speed, power 98 mA, config 1, USB Receiver(0xc505), Logitech(0x046d), rev 17.00 > port 4 powered > port 5 powered > port 6 addr 3: low speed, power 100 mA, config 1, product 0xffdc(0xffdc), vendor 0x15c2(0x15c2), rev 0.00 > port 7 powered > port 8 powered > Controller /dev/usb1: > addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), nVidia(0x0000), rev 1.00 > port 1 powered > port 2 addr 2: high speed, self powered, config 1, USB2.0 Hub(0x0606), vendor 0x05e3(0x05e3), rev 7.02 > port 1 addr 3: low speed, power 20 mA, config 1, ellipse(0xffff), MGE UPS SYSTEMS(0x0463), rev 0.01 > port 2 addr 4: full speed, self powered, config 1, Standard USB Hub(0x3301), vendor 0x03eb(0x03eb), rev 3.00 > port 1 addr 5: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 > port 2 addr 6: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 > port 3 addr 7: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 > port 4 addr 8: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 > port 3 powered > port 4 addr 9: full speed, power 86 mA, config 1, Bluetooth USB Adapter(0xb02a), vendor 0x07b8(0x07b8), rev 5.25 > port 3 powered > port 4 powered > port 5 powered > port 6 powered > port 7 powered > port 8 powered > > > > > Daniel Rich wrote: > >> Woo hoo!!! I'll pull this down and give it at try tonight. I need to >> pull the server down for a bit anyway, I just got the SPDIF interface >> for my motherboard, I want to see if that plays better with my stereo >> as well. >> >> Thanks, and I'll let you know how it goes. >> >> Alexander Popov wrote: >> >>> Hi, Daniel, All, >>> >>> I have published the very first version of the IMON driver for >>> FreeBSD. You can find it here: >>> http://www.xs4all.nl/~aopopov/imon/imon.html >>> Please note that this is still work in progress; I would definitely >>> appreciate any help in testing & feedback. >>> >>> Regards, >>> >>> Alexander. >>> >>> ----- Original Message ---- >>> From: Daniel Rich <dr...@em...> >>> To: alexx8 <ao...@ya...> >>> Cc: lir...@li... >>> Sent: Wednesday, May 21, 2008 8:27:04 PM >>> Subject: Re: LIRC on FreeBSD with a USB imon >>> >>> Wow, that's great news! I had been considering looking at porting >>> the driver over, but since I haven't done any driver work in >>> something like 20 years (and that was System V/386 streams drivers), >>> I was hoping that someone else had beat me to it. :) >>> >>> If you need someone to do more testing once you have it stable, let >>> me know. I'm not going to have any time to play with it until after >>> the first of June, but I would love to give it a try after that. >>> >>> Thanks again for the reply. >>> >>> alexx8 wrote: >>> >>>> Hi, Dan, >>>> >>>> It's not that easy. ugen is just an universal USB driver that gets attached >>>> to a device if no better matching driver is found. Getting imon to work with >>>> ugen would be quite some effort... >>>> Anyway, I have been developing (porting) linux imon driver to FreeBSD in my >>>> spare time (not much unfortunately), and I am going to publish it in the >>>> coming weeks. But you can already see how it looks like on my Silversone >>>> case running FreeBSD 7.0: http://www.xs4all.nl/~aopopov/imon/imon.html >>>> >>>> Regards, >>>> >>>> Alex. >>>> >>>> >>>> Dan Rich wrote: >>>> >>>> >>>>> I've decided to take another stab at getting my imon IR interface >>>>> working on my FreeBSD server. Unfortunately, it looks like there aren't >>>>> any kernel-level drivers for the imon (or any other lirc interfaces), >>>>> however it does show up as /dev/ugen1.1. I can cat the device and I see >>>>> data being received. For example running od -x against /dev/ugen1, I >>>>> normally see "ffff ffff ffff ff2e", and when I press the mute key on the >>>>> remote I see "952b b795 0000 012e". This seems to be close to what I >>>>> would expect from the imon lirc.conf file I am trying to use, the >>>>> imon_pad mute should send 0x2b9595b7. However, lircd doesn't seem to >>>>> like this, the log file contains: lircd: Really read 2 bytes from >>>>> '/dev/ugen1.1', expected 3 >>>>> >>>>> Does anyone have any suggestions on where I can go from here? Are the >>>>> special flags I need to convince lircd that it is connected to a usb >>>>> serial device? Am I out of luck unless I break down >>>>> and write a device >>>>> drive (ick)? >>>>> >>>>> Thanks! >>>>> >>>>> >>>>> > > > -- Dan Rich <dr...@em...> | http://www.employees.org/~drich/ | "Step up to red alert!" "Are you sure, sir? | It means changing the bulb in the sign..." | - Red Dwarf (BBC) |
From: Daniel R. <dr...@em...> - 2008-06-06 00:14:05
Attachments:
drich.vcf
|
Here's another data point, I just ran it where I can get to the remote and got the following from pressing volume up and channel up: imon: imonopen(u: 0, e: 1) - enter imon: successfully opened a pipe to IR imon: imonopen(u: 0, e: 1) - exit: 0 (1) imon: imonintr() - data = 28 a3 95 b7 00 00 2e 01 imon: imonintr() - data = 28 a3 d5 b7 00 00 2e 01 imon: imonintr() - data = 28 a3 95 b7 00 00 2e 01 imon: imonintr() - data = 28 a3 d5 b7 00 00 2e 01 imon: imonintr() - data = 28 a3 95 b7 00 00 2e 01 imon: imonintr() - data = 28 a3 d5 b7 00 00 2e 01 imon: imonintr() - data = 28 93 95 b7 00 00 2e 01 imon: imonintr() - data = 28 93 d5 b7 00 00 2e 01 imon: imonintr() - data = 28 93 95 b7 00 00 2e 01 imon: imonintr() - data = 28 93 d5 b7 00 00 2e 01 There is no output at all from ir_test however. Looking at the lirc.conf file for the imon-pad, it looks like those values are correct, but they aren't getting parsed by the driver. I have to run out for a bit, but I'll take a look at the code when I get back to see if anything obvious jumps out at me. Alexander Popov wrote: > Hi, Daniel, > > The fact that you see imon: imonintr() - data = bf ff ff ff 00 00 2e 01, etc. means IR part of the driver is working fine. I am sure that LIRC will work too, just check if you correctly followed my installation instructions. > However, the fact that you see imon: transferred 0 bytes and imon: transfer has failed, is troubling... maybe there is something with wiring? > > Regards, > Alexander. > > > ----- Original Message ---- > From: Daniel Rich <dr...@em...> > To: Alexander Popov <ao...@ya...> > Cc: lir...@li... > Sent: Thursday, June 5, 2008 11:00:58 PM > Subject: Re: LIRC on FreeBSD with a USB imon > > That's basically where I'm at right now, I just brought up lircd and > LCDd to see if they could talk to the devices. I rebooted last night > with just the driver loaded and both of those disabled, still no luck. > Your debugging ideas are exactly what I tried. > > I just tried running the lcd test (with one modification btw, I added a > ' or die "cannot open /dev/lcd0: $!"' to the open statement), and no > dice. Running a truss of it I see: > > open("/dev/lcd0",O_WRONLY|O_CREAT|O_TRUNC,0666) = 3 (0x3) > fstat(3,{mode=crw-r--r-- ,inode=114,size=0,blksize=4096}) = 0 (0x0) > fcntl(3,F_SETFD,FD_CLOEXEC) = 0 (0x0) > getdtablesize(0x1130,0xbfbfe890,0xbfbfe978,0x881789e4,0x0,0xbfbfe890) = 11095 (0x2b57) > fcntl(3,F_GETFL,) = 1 (0x1) > fstat(3,{mode=crw-r--r-- ,inode=114,size=0,blksize=4096}) = 0 (0x0) > ioctl(3,TIOCGETA,0xbfbfe920) = 0 (0x0) > fcntl(0,F_SETFD,0x0) = 0 (0x0) > fstat(0,{mode=crw--w---- ,inode=210,size=0,blksize=4096}) = 0 (0x0) > break(0x8068000) = 0 (0x0) > ioctl(0,TIOCGETA,0xbfbfc860) = 0 (0x0) > write(3," Powered by FreeBSD!",28) ERR#5 'Input/output error' > > > and dmesg tells me: > > imon: imonopen(u: 0, e: 0) - enter > imon: successfully opened a pipe to VFD > imon: imonopen(u: 0, e: 0) - exit: 0 (1) > imon: imonioctl(u: 0, e: 0, cmd: 402c7413) - enter > imon: ioctl is only implemented for IR - exit > imon: imonwrite(u: 0, e: 0) - enter > imon: vfd_transfer(device: imon0) - enter > imon: transferred 0 bytes > imon: transfer has failed > imon: vfd_transfer() - exit > imon: imonwrite(u: 0, e: 0) - exit: 5 > imon: imonclose(u: 0, e: 0) - enter > imon: user processes have all gone > imon: imonclose(u: 0, e: 0) - exit: 0 (0) > > > The good news is that I'm seeing data from the IR port at the moment. > The bad news is that I'm not at home, so it's hard to press buttons on > the remote remotely. :) Dmesg says: > > imon: imonopen(u: 0, e: 1) - enter > imon: successfully opened a pipe to IR > imon: imonopen(u: 0, e: 1) - exit: 0 (1) > imon: imonintr() - data = bf ff ff ff 00 00 2e 01 > imon: imonintr() - data = 7f ff ff ff 00 00 2e 01 > imon: imonintr() - data = ef ff ff ff 00 00 2e 01 > imon: imonclose(u: 0, e: 1) - enter > imon: imonintr() - status = cancelled > imon: user processes have all gone > imon: imonclose(u: 0, e: 1) - exit: 0 (0) > > > I'll have to do some more testing when I get home tonight. I may even > dig around in the driver code a bit if I get some time (ick :) ). > > Thanks again for working on this! > > Alexander Popov wrote: > >> Hi, Daniel, >> >> Sure there will be joy in mudville :-) From the debug info I see that you have exactly the same imon model as I; so it should work. The fact that it correctly detects the device and creates nodes under >> /dev, already indicates that at least half of the driver works. >> >> There are a few things that might help you: >> >> 1. there is a bug in my driver that prevents you from stopping LIRC daemon; so if you're testing, better remove lircd.sh from /usr/local/etc/rc.d and reboot. >> 2. The driver is not reentrant, i.e. if one client, say LIRCd opens /dev/lirc0, then running my test script ir_test.pl will simply fail. >> >> I suggest to start with small - just install the driver (that you already did), then, without starting LIRCd or LCDProc, run lcd_test.pl to test VFD. This script alone should print text into the display. If not, look what the driver has printed into the console: there are a lot of debugging information, and you should see /dev/lcd0 being open, and then text written to it. >> The same holds for ir_test.pl. What it does is simply opens /dev/lirc0 and then waits for user input. Do not press enter, but rather start pressing buttons on your remote. You should see button codes coming from the driver into the console. >> >> Let me know how it goes, I am sure we can get it working. >> >> Regards, >> >> Alexander. >> >> >> ----- Original Message ---- >> From: Daniel Rich <dr...@em...> >> To: Alexander Popov <ao...@ya...> >> Cc: lir...@li... >> Sent: Thursday, June 5, 2008 3:37:36 AM >> Subject: Re: LIRC on FreeBSD with a USB imon >> >> No joy in mudville. If I don't load the driver I can still see data >> coming from the ugen interface, but I don't get anything from /dev/lirc0 >> with the driver loaded using the test code or the patched lircd. It >> does see the device, and it created /dev/lirc0 and /dev/lcd0. >> >> Any thoughts on debugging? Here is what I see from the driver with >> debug enabled on boot: >> >> imon: USB_MATCH() - enter >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: checking idVendor = 0x463, idProduct = 0xffff >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: checking idVendor = 0x7b8, idProduct = 0xb02a >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: checking idVendor = 0x46d, idProduct = 0xc505 >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: checking idVendor = 0x46d, idProduct = 0xc505 >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: checking idVendor = 0x15c2, idProduct = 0xffdc >> imon: found a match, idVendor = 0x15c2, idProduct = 0xffdc >> imon: USB_MATCH() - exit: ffffffec >> imon: USB_MATCH() - enter >> imon: checking idVendor = 0x15c2, idProduct = 0xffdc >> imon: found a match, idVendor = 0x15c2, idProduct = 0xffdc >> imon: USB_MATCH() - exit: ffffffec >> imon0: <vendor 0x15c2 product 0xffdc, class 0/0, rev 1.10/0.00, addr 3> on uhub0 >> imon: USB_ATTACH(device: imon0) - enter >> imon: device supports 1 interfaces >> imon: device supports 2 endpoints >> imon: filter(): found endpoint nr 0 >> imon: filter(): using endpoint 0 (addr: 0x81) for IR output >> imon: filter(): found endpoint nr 1 >> imon: filter(): using endpoint 1 (addr: 0x2) for VFD input >> imon: VFD requires 6th packet: 1 >> imon: IR signals decoded onboard: 1 >> imon: successfully created device node for IR >> imon: successfully created device node for VFD >> imon: USB_ATTACH() - exit: 0 >> >> >> And from usbdevs -v: >> >> Controller /dev/usb0: >> addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), nVidia(0x0000), rev 1.00 >> port 1 powered >> port 2 powered >> port 3 addr 2: low speed, power 98 mA, config 1, USB Receiver(0xc505), Logitech(0x046d), rev 17.00 >> port 4 powered >> port 5 powered >> port 6 addr 3: low speed, power 100 mA, config 1, product 0xffdc(0xffdc), vendor 0x15c2(0x15c2), rev 0.00 >> port 7 powered >> port 8 powered >> Controller /dev/usb1: >> addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), nVidia(0x0000), rev 1.00 >> port 1 powered >> port 2 addr 2: high speed, self powered, config 1, USB2.0 Hub(0x0606), vendor 0x05e3(0x05e3), rev 7.02 >> port 1 addr 3: low speed, power 20 mA, config 1, ellipse(0xffff), MGE UPS SYSTEMS(0x0463), rev 0.01 >> port 2 addr 4: full speed, self powered, config 1, Standard USB Hub(0x3301), vendor 0x03eb(0x03eb), rev 3.00 >> port 1 addr 5: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 >> port 2 addr 6: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 >> port 3 addr 7: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 >> port 4 addr 8: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 >> port 3 powered >> port 4 addr 9: full speed, power 86 mA, config 1, Bluetooth USB Adapter(0xb02a), vendor 0x07b8(0x07b8), rev 5.25 >> port 3 powered >> port 4 powered >> port 5 powered >> port 6 powered >> port 7 powered >> port 8 powered >> >> >> >> >> Daniel Rich wrote: >> >> >>> Woo hoo!!! I'll pull this down and give it at try tonight. I need to >>> pull the server down for a bit anyway, I just got the SPDIF interface >>> for my motherboard, I want to see if that plays better with my stereo >>> as well. >>> >>> Thanks, and I'll let you know how it goes. >>> >>> Alexander Popov wrote: >>> >>> >>>> Hi, Daniel, All, >>>> >>>> I have published the very first version of the IMON driver for >>>> FreeBSD. You can find it here: >>>> http://www.xs4all.nl/~aopopov/imon/imon.html >>>> Please note that this is still work in progress; I would definitely >>>> appreciate any help in testing & feedback. >>>> >>>> Regards, >>>> >>>> Alexander. >>>> >>>> ----- Original Message ---- >>>> From: Daniel Rich <dr...@em...> >>>> To: alexx8 <ao...@ya...> >>>> Cc: lir...@li... >>>> Sent: Wednesday, May 21, 2008 8:27:04 PM >>>> Subject: Re: LIRC on FreeBSD with a USB imon >>>> >>>> Wow, that's great news! I had been considering looking at porting >>>> the driver over, but since I haven't done any driver work in >>>> something like 20 years (and that was System V/386 streams drivers), >>>> I was hoping that someone else had beat me to it. :) >>>> >>>> If you need someone to do more testing once you have it stable, let >>>> me know. I'm not going to have any time to play with it until after >>>> the first of June, but I would love to give it a try after that. >>>> >>>> Thanks again for the reply. >>>> >>>> alexx8 wrote: >>>> >>>> >>>>> Hi, Dan, >>>>> >>>>> It's not that easy. ugen is just an universal USB driver that gets attached >>>>> to a device if no better matching driver is found. Getting imon to work with >>>>> ugen would be quite some effort... >>>>> Anyway, I have been developing (porting) linux imon driver to FreeBSD in my >>>>> spare time (not much unfortunately), and I am going to publish it in the >>>>> coming weeks. But you can already see how it looks like on my Silversone >>>>> case running FreeBSD 7.0: http://www.xs4all.nl/~aopopov/imon/imon.html >>>>> >>>>> Regards, >>>>> >>>>> Alex. >>>>> >>>>> >>>>> Dan Rich wrote: >>>>> >>>>> >>>>> >>>>>> I've decided to take another stab at getting my imon IR interface >>>>>> working on my FreeBSD server. Unfortunately, it looks like there aren't >>>>>> any kernel-level drivers for the imon (or any other lirc interfaces), >>>>>> however it does show up as /dev/ugen1.1. I can cat the device and I see >>>>>> data being received. For example running od -x against /dev/ugen1, I >>>>>> normally see "ffff ffff ffff ff2e", and when I press the mute key on the >>>>>> remote I see "952b b795 0000 012e". This seems to be close to what I >>>>>> would expect from the imon lirc.conf file I am trying to use, the >>>>>> imon_pad mute should send 0x2b9595b7. However, lircd doesn't seem to >>>>>> like this, the log file contains: lircd: Really read 2 bytes from >>>>>> '/dev/ugen1.1', expected 3 >>>>>> >>>>>> Does anyone have any suggestions on where I can go from here? Are the >>>>>> special flags I need to convince lircd that it is connected to a usb >>>>>> serial device? Am I out of luck unless I break down >>>>>> and write a device >>>>>> drive (ick)? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> >>>>>> >>>>>> >> >> > > > -- Dan Rich <dr...@em...> | http://www.employees.org/~drich/ | "Step up to red alert!" "Are you sure, sir? | It means changing the bulb in the sign..." | - Red Dwarf (BBC) |
From: Alexander P. <ao...@ya...> - 2008-06-06 10:53:22
|
Daniel, that was the output :-) You're mixing things. Have a look over here to better understand what you're doing: http://www.lirc.org/html/technical.html#overview i.e. when you run ir_test, it simply opens the device that imon driver has created for you; at that level, there is no connection to lirc.conf and LICR daemon yet! At the next level is the LIRC daemon that connects to the /dev/lirc0, reads configuration file, i.e. lirc.conf, decodes data coming from the driver and publishes it at /var/run/lirc. Then, you can run test application like: irw /var/run/lirc to see how button codes are translated by the LIRC daemon into the textual names, i.e. Vol+ or Vol-. What you see at this moment is the debug info that driver prints when you open its device, i.e. /dev/lirc0. It means that driver works correctly, and that a client, like LIRC daemon will be able to read data from it. Please read LIRC documentation and installation instructions on my web-page. Regards, Alex. ----- Original Message ---- From: Daniel Rich <dr...@em...> To: Alexander Popov <ao...@ya...> Cc: lir...@li... Sent: Friday, June 6, 2008 2:13:58 AM Subject: Re: LIRC on FreeBSD with a USB imon Here's another data point, I just ran it where I can get to the remote and got the following from pressing volume up and channel up: imon: imonopen(u: 0, e: 1) - enter imon: successfully opened a pipe to IR imon: imonopen(u: 0, e: 1) - exit: 0 (1) imon: imonintr() - data = 28 a3 95 b7 00 00 2e 01 imon: imonintr() - data = 28 a3 d5 b7 00 00 2e 01 imon: imonintr() - data = 28 a3 95 b7 00 00 2e 01 imon: imonintr() - data = 28 a3 d5 b7 00 00 2e 01 imon: imonintr() - data = 28 a3 95 b7 00 00 2e 01 imon: imonintr() - data = 28 a3 d5 b7 00 00 2e 01 imon: imonintr() - data = 28 93 95 b7 00 00 2e 01 imon: imonintr() - data = 28 93 d5 b7 00 00 2e 01 imon: imonintr() - data = 28 93 95 b7 00 00 2e 01 imon: imonintr() - data = 28 93 d5 b7 00 00 2e 01 There is no output at all from ir_test however. Looking at the lirc.conf file for the imon-pad, it looks like those values are correct, but they aren't getting parsed by the driver. I have to run out for a bit, but I'll take a look at the code when I get back to see if anything obvious jumps out at me. Alexander Popov wrote: > Hi, Daniel, > > The fact that you see imon: imonintr() - data = bf ff ff ff 00 00 2e 01, etc. means IR part of the driver is working fine. I am sure that LIRC will work too, just check if you correctly followed my installation instructions. > However, the fact that you see imon: transferred 0 bytes and imon: transfer has failed, is troubling... maybe there is something with wiring? > > Regards, > Alexander. > > > ----- Original Message ---- > From: Daniel Rich <dr...@em...> > To: Alexander Popov <ao...@ya...> > Cc: lir...@li... > Sent: Thursday, June 5, 2008 11:00:58 PM > Subject: Re: LIRC on FreeBSD with a USB imon > > That's basically where I'm at right now, I just brought up lircd and > LCDd to see if they could talk to the devices. I rebooted last night > with just the driver loaded and both of those disabled, still no luck. > Your debugging ideas are exactly what I tried. > > I just tried running the lcd test (with one modification btw, I added a > ' or die "cannot open /dev/lcd0: $!"' to the open statement), and no > dice. Running a truss of it I see: > > open("/dev/lcd0",O_WRONLY|O_CREAT|O_TRUNC,0666) = 3 (0x3) > fstat(3,{mode=crw-r--r-- ,inode=114,size=0,blksize=4096}) = 0 (0x0) > fcntl(3,F_SETFD,FD_CLOEXEC) = 0 (0x0) > getdtablesize(0x1130,0xbfbfe890,0xbfbfe978,0x881789e4,0x0,0xbfbfe890) = 11095 (0x2b57) > fcntl(3,F_GETFL,) = 1 (0x1) > fstat(3,{mode=crw-r--r-- ,inode=114,size=0,blksize=4096}) = 0 (0x0) > ioctl(3,TIOCGETA,0xbfbfe920) = 0 (0x0) > fcntl(0,F_SETFD,0x0) = 0 (0x0) > fstat(0,{mode=crw--w---- ,inode=210,size=0,blksize=4096}) = 0 (0x0) > break(0x8068000) = 0 (0x0) > ioctl(0,TIOCGETA,0xbfbfc860) = 0 (0x0) > write(3," Powered by FreeBSD!",28) ERR#5 'Input/output error' > > > and dmesg tells me: > > imon: imonopen(u: 0, e: 0) - enter > imon: successfully opened a pipe to VFD > imon: imonopen(u: 0, e: 0) - exit: 0 (1) > imon: imonioctl(u: 0, e: 0, cmd: 402c7413) - enter > imon: ioctl is only implemented for IR - exit > imon: imonwrite(u: 0, e: 0) - enter > imon: vfd_transfer(device: imon0) - enter > imon: transferred 0 bytes > imon: transfer has failed > imon: vfd_transfer() - exit > imon: imonwrite(u: 0, e: 0) - exit: 5 > imon: imonclose(u: 0, e: 0) - enter > imon: user processes have all gone > imon: imonclose(u: 0, e: 0) - exit: 0 (0) > > > The good news is that I'm seeing data from the IR port at the moment. > The bad news is that I'm not at home, so it's hard to press buttons on > the remote remotely. :) Dmesg says: > > imon: imonopen(u: 0, e: 1) - enter > imon: successfully opened a pipe to IR > imon: imonopen(u: 0, e: 1) - exit: 0 (1) > imon: imonintr() - data = bf ff ff ff 00 00 2e 01 > imon: imonintr() - data = 7f ff ff ff 00 00 2e 01 > imon: imonintr() - data = ef ff ff ff 00 00 2e 01 > imon: imonclose(u: 0, e: 1) - enter > imon: imonintr() - status = cancelled > imon: user processes have all gone > imon: imonclose(u: 0, e: 1) - exit: 0 (0) > > > I'll have to do some more testing when I get home tonight. I may even > dig around in the driver code a bit if I get some time (ick :) ). > > Thanks again for working on this! > > Alexander Popov wrote: > >> Hi, Daniel, >> >> Sure there will be joy in mudville :-) From the debug info I see that you have exactly the same imon model as I; so it should work. The fact that it correctly detects the device and creates nodes under >> /dev, already indicates that at least half of the driver works. >> >> There are a few things that might help you: >> >> 1. there is a bug in my driver that prevents you from stopping LIRC daemon; so if you're testing, better remove lircd.sh from /usr/local/etc/rc.d and reboot. >> 2. The driver is not reentrant, i.e. if one client, say LIRCd opens /dev/lirc0, then running my test script ir_test.pl will simply fail. >> >> I suggest to start with small - just install the driver (that you already did), then, without starting LIRCd or LCDProc, run lcd_test.pl to test VFD. This script alone should print text into the display. If not, look what the driver has printed into the console: there are a lot of debugging information, and you should see /dev/lcd0 being open, and then text written to it. >> The same holds for ir_test.pl. What it does is simply opens /dev/lirc0 and then waits for user input. Do not press enter, but rather start pressing buttons on your remote. You should see button codes coming from the driver into the console. >> >> Let me know how it goes, I am sure we can get it working. >> >> Regards, >> >> Alexander. >> >> >> ----- Original Message ---- >> From: Daniel Rich <dr...@em...> >> To: Alexander Popov <ao...@ya...> >> Cc: lir...@li... >> Sent: Thursday, June 5, 2008 3:37:36 AM >> Subject: Re: LIRC on FreeBSD with a USB imon >> >> No joy in mudville. If I don't load the driver I can still see data >> coming from the ugen interface, but I don't get anything from /dev/lirc0 >> with the driver loaded using the test code or the patched lircd. It >> does see the device, and it created /dev/lirc0 and /dev/lcd0. >> >> Any thoughts on debugging? Here is what I see from the driver with >> debug enabled on boot: >> >> imon: USB_MATCH() - enter >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: checking idVendor = 0x463, idProduct = 0xffff >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: checking idVendor = 0x7b8, idProduct = 0xb02a >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: checking idVendor = 0x46d, idProduct = 0xc505 >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: checking idVendor = 0x46d, idProduct = 0xc505 >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: USB_MATCH() - exit: 6 >> imon: USB_MATCH() - enter >> imon: checking idVendor = 0x15c2, idProduct = 0xffdc >> imon: found a match, idVendor = 0x15c2, idProduct = 0xffdc >> imon: USB_MATCH() - exit: ffffffec >> imon: USB_MATCH() - enter >> imon: checking idVendor = 0x15c2, idProduct = 0xffdc >> imon: found a match, idVendor = 0x15c2, idProduct = 0xffdc >> imon: USB_MATCH() - exit: ffffffec >> imon0: <vendor 0x15c2 product 0xffdc, class 0/0, rev 1.10/0.00, addr 3> on uhub0 >> imon: USB_ATTACH(device: imon0) - enter >> imon: device supports 1 interfaces >> imon: device supports 2 endpoints >> imon: filter(): found endpoint nr 0 >> imon: filter(): using endpoint 0 (addr: 0x81) for IR output >> imon: filter(): found endpoint nr 1 >> imon: filter(): using endpoint 1 (addr: 0x2) for VFD input >> imon: VFD requires 6th packet: 1 >> imon: IR signals decoded onboard: 1 >> imon: successfully created device node for IR >> imon: successfully created device node for VFD >> imon: USB_ATTACH() - exit: 0 >> >> >> And from usbdevs -v: >> >> Controller /dev/usb0: >> addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), nVidia(0x0000), rev 1.00 >> port 1 powered >> port 2 powered >> port 3 addr 2: low speed, power 98 mA, config 1, USB Receiver(0xc505), Logitech(0x046d), rev 17.00 >> port 4 powered >> port 5 powered >> port 6 addr 3: low speed, power 100 mA, config 1, product 0xffdc(0xffdc), vendor 0x15c2(0x15c2), rev 0.00 >> port 7 powered >> port 8 powered >> Controller /dev/usb1: >> addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), nVidia(0x0000), rev 1.00 >> port 1 powered >> port 2 addr 2: high speed, self powered, config 1, USB2.0 Hub(0x0606), vendor 0x05e3(0x05e3), rev 7.02 >> port 1 addr 3: low speed, power 20 mA, config 1, ellipse(0xffff), MGE UPS SYSTEMS(0x0463), rev 0.01 >> port 2 addr 4: full speed, self powered, config 1, Standard USB Hub(0x3301), vendor 0x03eb(0x03eb), rev 3.00 >> port 1 addr 5: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 >> port 2 addr 6: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 >> port 3 addr 7: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 >> port 4 addr 8: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 >> port 3 powered >> port 4 addr 9: full speed, power 86 mA, config 1, Bluetooth USB Adapter(0xb02a), vendor 0x07b8(0x07b8), rev 5.25 >> port 3 powered >> port 4 powered >> port 5 powered >> port 6 powered >> port 7 powered >> port 8 powered >> >> >> >> >> Daniel Rich wrote: >> >> >>> Woo hoo!!! I'll pull this down and give it at try tonight. I need to >>> pull the server down for a bit anyway, I just got the SPDIF interface >>> for my motherboard, I want to see if that plays better with my stereo >>> as well. >>> >>> Thanks, and I'll let you know how it goes. >>> >>> Alexander Popov wrote: >>> >>> >>>> Hi, Daniel, All, >>>> >>>> I have published the very first version of the IMON driver for >>>> FreeBSD. You can find it here: >>>> http://www.xs4all.nl/~aopopov/imon/imon.html >>>> Please note that this is still work in progress; I would definitely >>>> appreciate any help in testing & feedback. >>>> >>>> Regards, >>>> >>>> Alexander. >>>> >>>> ----- Original Message ---- >>>> From: Daniel Rich <dr...@em...> >>>> To: alexx8 <ao...@ya...> >>>> Cc: lir...@li... >>>> Sent: Wednesday, May 21, 2008 8:27:04 PM >>>> Subject: Re: LIRC on FreeBSD with a USB imon >>>> >>>> Wow, that's great news! I had been considering looking at porting >>>> the driver over, but since I haven't done any driver work in >>>> something like 20 years (and that was System V/386 streams drivers), >>>> I was hoping that someone else had beat me to it. :) >>>> >>>> If you need someone to do more testing once you have it stable, let >>>> me know. I'm not going to have any time to play with it until after >>>> the first of June, but I would love to give it a try after that. >>>> >>>> Thanks again for the reply. >>>> >>>> alexx8 wrote: >>>> >>>> >>>>> Hi, Dan, >>>>> >>>>> It's not that easy. ugen is just an universal USB driver that gets attached >>>>> to a device if no better matching driver is found. Getting imon to work with >>>>> ugen would be quite some effort... >>>>> Anyway, I have been developing (porting) linux imon driver to FreeBSD in my >>>>> spare time (not much unfortunately), and I am going to publish it in the >>>>> coming weeks. But you can already see how it looks like on my Silversone >>>>> case running FreeBSD 7.0: http://www.xs4all.nl/~aopopov/imon/imon.html >>>>> >>>>> Regards, >>>>> >>>>> Alex. >>>>> >>>>> >>>>> Dan Rich wrote: >>>>> >>>>> >>>>> >>>>>> I've decided to take another stab at getting my imon IR interface >>>>>> working on my FreeBSD server. Unfortunately, it looks like there aren't >>>>>> any kernel-level drivers for the imon (or any other lirc interfaces), >>>>>> however it does show up as /dev/ugen1.1. I can cat the device and I see >>>>>> data being received. For example running od -x against /dev/ugen1, I >>>>>> normally see "ffff ffff ffff ff2e", and when I press the mute key on the >>>>>> remote I see "952b b795 0000 012e". This seems to be close to what I >>>>>> would expect from the imon lirc.conf file I am trying to use, the >>>>>> imon_pad mute should send 0x2b9595b7. However, lircd doesn't seem to >>>>>> like this, the log file contains: lircd: Really read 2 bytes from >>>>>> '/dev/ugen1.1', expected 3 >>>>>> >>>>>> Does anyone have any suggestions on where I can go from here? Are the >>>>>> special flags I need to convince lircd that it is connected to a usb >>>>>> serial device? Am I out of luck unless I break down >>>>>> and write a device >>>>>> drive (ick)? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> >>>>>> >>>>>> >> >> > > > -- Dan Rich <dr...@em...> | http://www.employees.org/~drich/ | "Step up to red alert!" "Are you sure, sir? | It means changing the bulb in the sign..." | - Red Dwarf (BBC) |
From: Daniel R. <dr...@em...> - 2010-02-04 19:39:50
Attachments:
signature.asc
|
Alex, I'm back to trying to get imon up and running now that I've upgraded to FreeBSD 8.0. It appears to have much better USB support, so hopefully it will fix my communication issues and disappearing USB devices (I lose my UPS after a few hours, it's really frustrating). However, they included libusb in the OS now and in the process have done odd things to the header files. There is also an issue mentioned on the nut mailing list that they aren't including sys/types.h so it has to be included at the app level (this didn't help with trying to get imon.ko to build though). Have you done anything with your driver in ages? I'm hoping that you've tried building it on 8.0 to save me the headache of trying to port it... To start with I've had to force CFLAGS in the makefile, something in the system make system isn't including /usr/include, so it can't find dev/usb.h. Once I do that it at least finds the header, but throws quite a few errors, I'll include them below. The odd thing is that usbd_interface_handle and usbd_device_handle are referenced in a lot of the files in /usr/include/dev/usb, but I don't see typedefs or #defines for them anywhere. Have you looked at linux-kmod-compat? It's a neat little module to allow linux drivers to build on FreeBSD. The author has it working with a handful of USB webcam drivers, unfortunately I'm having some of the same issues as above trying to get them to build on FreeBSD 8.0... Thanks! Here is the compiler output after adding CFLAGS+=/usr/include to the makefile: drich@morpheus|553> make Warning: Object directory not changed from original /home/drich/Src/imon-0.1 awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h :> opt_usb.h cc -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/usr/include -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c imon.c imon.c:80: error: expected specifier-qualifier-list before 'usbd_interface_handle' imon.c:109: error: expected specifier-qualifier-list before 'usbd_device_handle' imon.c:140: error: expected ')' before 'xfer' imon.c:191: error: expected declaration specifiers or '...' before 'usbd_interface_handle' imon.c:194: error: expected declaration specifiers or '...' before 'usbd_xfer_handle' imon.c:195: error: expected declaration specifiers or '...' before 'usbd_pipe_handle' imon.c: In function 'imon_match': imon.c:210: error: 'UMATCH_NONE' undeclared (first use in this function) imon.c:210: error: (Each undeclared identifier is reported only once imon.c:210: error: for each function it appears in.) imon.c:240: error: 'UMATCH_VENDOR_PRODUCT' undeclared (first use in this function) imon.c: In function 'imon_attach': imon.c:252: error: 'usbd_status' undeclared (first use in this function) imon.c:252: error: expected ';' before 'result' cc1: warnings being treated as errors imon.c:254: warning: implicit declaration of function 'usbd_devinfo' imon.c:254: warning: nested extern declaration of 'usbd_devinfo' imon.c:262: error: 'struct imon_softc' has no member named 'udev' imon.c:267: error: 'result' undeclared (first use in this function) imon.c:267: error: 'USBD_NORMAL_COMPLETION' undeclared (first use in this function) imon.c:269: error: 'struct imon_softc' has no member named 'udev' imon.c:284: error: 'usbd_interface_handle' undeclared (first use in this function) imon.c:284: error: expected ';' before 'iface' imon.c:288: warning: implicit declaration of function 'usbd_device2interface_handle' imon.c:288: warning: nested extern declaration of 'usbd_device2interface_handle' imon.c:288: error: 'struct imon_softc' has no member named 'udev' imon.c:288: error: 'iface' undeclared (first use in this function) imon.c:300: warning: implicit declaration of function 'usbd_endpoint_count' imon.c:300: warning: nested extern declaration of 'usbd_endpoint_count' imon.c:318: warning: implicit declaration of function 'usbd_interface2endpoint_descriptor' imon.c:318: warning: nested extern declaration of 'usbd_interface2endpoint_descriptor' imon.c:318: warning: assignment makes pointer from integer without a cast imon.c:319: warning: passing argument 3 of 'filter_store_endpoint' makes pointer from integer without a cast imon.c:319: error: too many arguments to function 'filter_store_endpoint' imon.c:328: error: 'struct imon_softc' has no member named 'udev' imon.c:340: error: 'struct imon_softc' has no member named 'vfd_proto_6p' imon.c:353: error: 'struct imon_softc' has no member named 'udev' imon.c:365: error: 'struct imon_softc' has no member named 'ir_onboard_decode' imon.c:377: error: 'struct imon_softc' has no member named 'endpoints' imon.c:398: error: 'struct imon_softc' has no member named 'endpoints' imon.c:418: warning: control reaches end of non-void function imon.c: In function 'imon_detach': imon.c:424: error: 'usbd_status' undeclared (first use in this function) imon.c:424: error: expected ';' before 'result' imon.c:430: error: 'struct imon_softc' has no member named 'imon_mtx' imon.c:433: error: 'result' undeclared (first use in this function) imon.c:433: error: 'USBD_NORMAL_COMPLETION' undeclared (first use in this function) imon.c:437: error: 'struct imon_softc' has no member named 'endpoints' imon.c:439: warning: implicit declaration of function 'usbd_abort_pipe' imon.c:439: warning: nested extern declaration of 'usbd_abort_pipe' imon.c:439: error: 'struct imon_softc' has no member named 'endpoints' imon.c:440: warning: implicit declaration of function 'usbd_close_pipe' imon.c:440: warning: nested extern declaration of 'usbd_close_pipe' imon.c:440: error: 'struct imon_softc' has no member named 'endpoints' imon.c:441: error: 'struct imon_softc' has no member named 'endpoints' imon.c:447: error: 'struct imon_softc' has no member named 'state' imon.c:448: error: 'struct imon_softc' has no member named 'endpoints' imon.c:451: error: 'struct imon_softc' has no member named 'imon_mtx' imon.c:456: error: 'struct imon_softc' has no member named 'imon_mtx' imon.c:457: error: 'struct imon_softc' has no member named 'imon_refcnt' imon.c:469: error: 'struct imon_softc' has no member named 'imon_mtx' imon.c:490: warning: control reaches end of non-void function imon.c: In function 'imonopen': imon.c:495: error: invalid operands to binary & imon.c:496: error: invalid operands to binary & imon.c:498: error: 'usbd_status' undeclared (first use in this function) imon.c:498: error: expected ';' before 'status' imon.c:504: error: 'struct imon_softc' has no member named 'imon_mtx' imon.c:509: error: 'struct imon_softc' has no member named 'state' imon.c:519: error: 'struct imon_softc' has no member named 'endpoints' imon.c:528: error: 'struct imon_softc' has no member named 'endpoints' imon.c:531: error: 'status' undeclared (first use in this function) imon.c:531: warning: implicit declaration of function 'usbd_open_pipe' imon.c:531: warning: nested extern declaration of 'usbd_open_pipe' imon.c:531: error: 'struct imon_softc' has no member named 'endpoints' imon.c:532: error: 'struct imon_softc' has no member named 'endpoints' imon.c:534: error: 'struct imon_softc' has no member named 'endpoints' imon.c:536: error: 'USBD_NORMAL_COMPLETION' undeclared (first use in this function) imon.c:549: error: 'struct imon_softc' has no member named 'endpoints' imon.c:551: error: 'struct imon_softc' has no member named 'endpoints' imon.c:552: error: 'struct imon_endpoint' has no member named 'epdesc' imon.c:552: error: 'struct imon_endpoint' has no member named 'epdesc' imon.c:553: error: 'struct imon_endpoint' has no member named 'ibuf' imon.c:554: warning: implicit declaration of function 'clist_alloc_cblocks' imon.c:554: warning: nested extern declaration of 'clist_alloc_cblocks' imon.c:554: error: 'struct imon_endpoint' has no member named 'iqueue' imon.c:556: warning: implicit declaration of function 'usbd_open_pipe_intr' imon.c:556: warning: nested extern declaration of 'usbd_open_pipe_intr' imon.c:556: error: 'struct imon_endpoint' has no member named 'iface' imon.c:557: error: 'struct imon_endpoint' has no member named 'epdesc' imon.c:558: error: 'USBD_SHORT_XFER_OK' undeclared (first use in this function) imon.c:559: error: 'struct imon_endpoint' has no member named 'pipeh' imon.c:561: error: 'struct imon_endpoint' has no member named 'ibuf' imon.c:563: error: 'imonintr' undeclared (first use in this function) imon.c:564: error: 'USBD_DEFAULT_INTERVAL' undeclared (first use in this function) imon.c:573: error: 'struct imon_endpoint' has no member named 'ibuf' imon.c:574: error: 'struct imon_endpoint' has no member named 'ibuf' imon.c:575: warning: implicit declaration of function 'clist_free_cblocks' imon.c:575: warning: nested extern declaration of 'clist_free_cblocks' imon.c:575: error: 'struct imon_endpoint' has no member named 'iqueue' imon.c:583: error: 'struct imon_softc' has no member named 'imon_refcnt' imon.c:587: error: 'struct imon_softc' has no member named 'imon_mtx' imon.c: In function 'imonclose': imon.c:597: error: invalid operands to binary & imon.c:598: error: invalid operands to binary & imon.c:605: error: 'struct imon_softc' has no member named 'imon_mtx' imon.c:607: error: 'struct imon_softc' has no member named 'endpoints' imon.c:609: error: 'struct imon_softc' has no member named 'endpoints' imon.c:610: error: 'struct imon_softc' has no member named 'endpoints' imon.c:611: error: 'struct imon_softc' has no member named 'endpoints' imon.c:617: error: 'struct imon_softc' has no member named 'endpoints' imon.c:618: warning: implicit declaration of function 'ndflush' imon.c:618: warning: nested extern declaration of 'ndflush' imon.c:618: error: 'struct imon_endpoint' has no member named 'iqueue' imon.c:618: error: 'struct imon_endpoint' has no member named 'iqueue' imon.c:619: error: 'struct imon_endpoint' has no member named 'iqueue' imon.c:620: error: 'struct imon_endpoint' has no member named 'ibuf' imon.c:622: error: 'struct imon_endpoint' has no member named 'ibuf' imon.c:623: error: 'struct imon_endpoint' has no member named 'ibuf' imon.c:628: error: 'struct imon_softc' has no member named 'imon_refcnt' imon.c:629: error: 'struct imon_softc' has no member named 'imon_refcnt' imon.c:633: error: 'struct imon_softc' has no member named 'imon_cv' imon.c:634: error: 'struct imon_softc' has no member named 'imon_refcnt' imon.c:638: error: 'struct imon_softc' has no member named 'imon_mtx' imon.c: In function 'imonwrite': imon.c:651: error: invalid operands to binary & imon.c:652: error: invalid operands to binary & imon.c:659: error: 'struct imon_softc' has no member named 'imon_mtx' imon.c:664: error: 'struct imon_softc' has no member named 'state' imon.c:683: error: 'struct imon_softc' has no member named 'endpoints' imon.c:728: error: 'usbd_xfer_handle' undeclared (first use in this function) imon.c:728: error: expected ';' before 'xfer' imon.c:733: error: 'xfer' undeclared (first use in this function) imon.c:733: warning: implicit declaration of function 'usbd_alloc_xfer' imon.c:733: warning: nested extern declaration of 'usbd_alloc_xfer' imon.c:733: error: 'struct imon_softc' has no member named 'udev' imon.c:756: error: 'struct imon_softc' has no member named 'endpoints' imon.c:757: error: too many arguments to function 'vfd_transfer' imon.c:772: error: 'struct imon_softc' has no member named 'vfd_proto_6p' imon.c:779: error: 'struct imon_softc' has no member named 'endpoints' imon.c:780: error: too many arguments to function 'vfd_transfer' imon.c:787: warning: implicit declaration of function 'usbd_free_xfer' imon.c:787: warning: nested extern declaration of 'usbd_free_xfer' imon.c:791: error: 'struct imon_softc' has no member named 'imon_mtx' imon.c: In function 'imonread': imon.c:801: error: invalid operands to binary & imon.c:802: error: invalid operands to binary & imon.c:809: error: 'struct imon_softc' has no member named 'imon_mtx' imon.c:814: error: 'struct imon_softc' has no member named 'state' imon.c:833: error: 'struct imon_softc' has no member named 'endpoints' imon.c:840: error: 'struct imon_softc' has no member named 'endpoints' imon.c:843: error: 'struct imon_endpoint' has no member named 'iqueue' imon.c:853: error: 'struct imon_endpoint' has no member named 'iqueue' imon.c:856: error: 'struct imon_softc' has no member named 'state' imon.c:857: error: 'struct imon_softc' has no member named 'imon_mtx' imon.c:860: error: 'struct imon_softc' has no member named 'state' imon.c:864: error: 'struct imon_softc' has no member named 'state' imon.c:876: error: 'struct imon_endpoint' has no member named 'iqueue' imon.c:879: error: 'struct imon_endpoint' has no member named 'iqueue' imon.c:886: warning: implicit declaration of function 'q_to_b' imon.c:886: warning: nested extern declaration of 'q_to_b' imon.c:886: error: 'struct imon_endpoint' has no member named 'iqueue' imon.c:895: error: 'struct imon_softc' has no member named 'imon_mtx' imon.c: In function 'imonioctl': imon.c:906: error: invalid operands to binary & imon.c:907: error: invalid operands to binary & imon.c:927: error: 'struct imon_softc' has no member named 'endpoints' imon.c:937: error: 'struct imon_softc' has no member named 'ir_onboard_decode' imon.c:985: error: 'struct imon_softc' has no member named 'ir_onboard_decode' imon.c: In function 'init_softc': imon.c:1017: error: 'struct imon_softc' has no member named 'udev' imon.c:1018: error: 'struct imon_softc' has no member named 'vfd_proto_6p' imon.c:1019: error: 'struct imon_softc' has no member named 'ir_onboard_decode' imon.c:1020: error: 'struct imon_softc' has no member named 'state' imon.c:1021: error: 'struct imon_softc' has no member named 'imon_refcnt' imon.c:1027: error: 'struct imon_softc' has no member named 'endpoints' imon.c:1028: error: 'struct imon_softc' has no member named 'endpoints' imon.c:1029: error: 'struct imon_softc' has no member named 'endpoints' imon.c:1030: error: 'struct imon_softc' has no member named 'endpoints' imon.c:1032: error: 'struct imon_softc' has no member named 'endpoints' imon.c:1033: error: 'struct imon_softc' has no member named 'endpoints' imon.c:1034: error: 'struct imon_softc' has no member named 'endpoints' imon.c:1038: error: 'struct imon_softc' has no member named 'imon_mtx' imon.c:1040: error: 'struct imon_softc' has no member named 'imon_cv' imon.c: In function 'cleanup_softc': imon.c:1047: error: 'struct imon_softc' has no member named 'imon_mtx' imon.c:1048: error: 'struct imon_softc' has no member named 'imon_cv' imon.c:1050: error: 'struct imon_softc' has no member named 'state' imon.c: At top level: imon.c:1056: error: expected declaration specifiers or '...' before 'usbd_interface_handle' imon.c: In function 'filter_store_endpoint': imon.c:1084: error: 'struct imon_softc' has no member named 'endpoints' imon.c:1084: error: 'iface' undeclared (first use in this function) imon.c:1085: error: 'struct imon_softc' has no member named 'endpoints' imon.c:1094: error: 'struct imon_softc' has no member named 'endpoints' imon.c:1095: error: 'struct imon_softc' has no member named 'endpoints' imon.c: At top level: imon.c:1109: error: expected declaration specifiers or '...' before 'usbd_xfer_handle' imon.c:1110: error: expected declaration specifiers or '...' before 'usbd_pipe_handle' imon.c: In function 'vfd_transfer': imon.c:1112: error: 'usbd_status' undeclared (first use in this function) imon.c:1112: error: expected ';' before 'status' imon.c:1119: error: 'status' undeclared (first use in this function) imon.c:1119: warning: implicit declaration of function 'usbd_intr_transfer' imon.c:1119: warning: nested extern declaration of 'usbd_intr_transfer' imon.c:1119: error: 'xfer' undeclared (first use in this function) imon.c:1119: error: 'pipeh' undeclared (first use in this function) imon.c:1120: error: 'USBD_DEFAULT_TIMEOUT' undeclared (first use in this function) imon.c:1125: error: 'USBD_NORMAL_COMPLETION' undeclared (first use in this function) imon.c:1127: error: 'USBD_INTERRUPTED' undeclared (first use in this function) imon.c:1132: error: 'USBD_TIMEOUT' undeclared (first use in this function) imon.c: At top level: imon.c:1149: error: expected ')' before 'xfer' imon.c: In function 'submit_data': imon.c:1311: error: 'struct imon_softc' has no member named 'endpoints' imon.c:1313: error: 'struct imon_endpoint' has no member named 'dec_count' imon.c:1318: error: 'struct imon_endpoint' has no member named 'dec_prev_bit' imon.c:1328: warning: implicit declaration of function 'b_to_q' imon.c:1328: warning: nested extern declaration of 'b_to_q' imon.c:1328: error: 'struct imon_endpoint' has no member named 'iqueue' imon.c:1329: error: 'struct imon_softc' has no member named 'state' imon.c: At top level: imon.c:1338: error: 'usbd_driver_load' undeclared here (not in a function) *** Error code 1 Alexander Popov wrote: > Daniel, that was the output :-) > You're mixing things. Have a look over here to better understand what you're doing: http://www.lirc.org/html/technical.html#overview > > i.e. when you run ir_test, it simply opens the device that imon driver has created for you; at that level, there is no connection to lirc.conf and LICR daemon yet! At the next level is the LIRC daemon that connects to the /dev/lirc0, reads configuration file, i.e. lirc.conf, decodes data coming from the driver and publishes it at /var/run/lirc. Then, you can run test application like: > irw /var/run/lirc > to see how button codes are translated by the LIRC daemon into the textual names, i.e. Vol+ or Vol-. > > What you see at this moment is the debug info that driver prints when you open its device, i.e. /dev/lirc0. It means that driver works correctly, and that a client, like LIRC daemon will be able to read data from it. Please read LIRC documentation and installation instructions on my web-page. > > Regards, > > Alex. > > > ----- Original Message ---- > From: Daniel Rich <dr...@em...> > To: Alexander Popov <ao...@ya...> > Cc: lir...@li... > Sent: Friday, June 6, 2008 2:13:58 AM > Subject: Re: LIRC on FreeBSD with a USB imon > > Here's another data point, I just ran it where I can get to the remote > and got the following from pressing volume up and channel up: > > imon: imonopen(u: 0, e: 1) - enter > imon: successfully opened a pipe to IR > imon: imonopen(u: 0, e: 1) - exit: 0 (1) > imon: imonintr() - data = 28 a3 95 b7 00 00 2e 01 > imon: imonintr() - data = 28 a3 d5 b7 00 00 2e 01 > imon: imonintr() - data = 28 a3 95 b7 00 00 2e 01 > imon: imonintr() - data = 28 a3 d5 b7 00 00 2e 01 > imon: imonintr() - data = 28 a3 95 b7 00 00 2e 01 > imon: imonintr() - data = 28 a3 d5 b7 00 00 2e 01 > imon: imonintr() - data = 28 93 95 b7 00 00 2e 01 > imon: imonintr() - data = 28 93 d5 b7 00 00 2e 01 > imon: imonintr() - data = 28 93 95 b7 00 00 2e 01 > imon: imonintr() - data = 28 93 d5 b7 00 00 2e 01 > > > There is no output at all from ir_test however. Looking at the > lirc.conf file for the imon-pad, it looks like those values are correct, > but they aren't getting parsed by the driver. I have to run out for a > bit, but I'll take a look at the code when I get back to see if anything > obvious jumps out at me. > > Alexander Popov wrote: > >> Hi, Daniel, >> >> The fact that you see imon: imonintr() - data = bf ff ff ff 00 00 2e 01, etc. means IR part of the driver is working fine. I am sure that LIRC will work too, just check if you correctly followed my installation instructions. >> However, the fact that you see imon: transferred 0 bytes and imon: transfer has failed, is troubling... maybe there is something with wiring? >> >> Regards, >> Alexander. >> >> >> ----- Original Message ---- >> From: Daniel Rich <dr...@em...> >> To: Alexander Popov <ao...@ya...> >> Cc: lir...@li... >> Sent: Thursday, June 5, 2008 11:00:58 PM >> Subject: Re: LIRC on FreeBSD with a USB imon >> >> That's basically where I'm at right now, I just brought up lircd and >> LCDd to see if they could talk to the devices. I rebooted last night >> with just the driver loaded and both of those disabled, still no luck. >> Your debugging ideas are exactly what I tried. >> >> I just tried running the lcd test (with one modification btw, I added a >> ' or die "cannot open /dev/lcd0: $!"' to the open statement), and no >> dice. Running a truss of it I see: >> >> open("/dev/lcd0",O_WRONLY|O_CREAT|O_TRUNC,0666) = 3 (0x3) >> fstat(3,{mode=crw-r--r-- ,inode=114,size=0,blksize=4096}) = 0 (0x0) >> fcntl(3,F_SETFD,FD_CLOEXEC) = 0 (0x0) >> getdtablesize(0x1130,0xbfbfe890,0xbfbfe978,0x881789e4,0x0,0xbfbfe890) = 11095 (0x2b57) >> fcntl(3,F_GETFL,) = 1 (0x1) >> fstat(3,{mode=crw-r--r-- ,inode=114,size=0,blksize=4096}) = 0 (0x0) >> ioctl(3,TIOCGETA,0xbfbfe920) = 0 (0x0) >> fcntl(0,F_SETFD,0x0) = 0 (0x0) >> fstat(0,{mode=crw--w---- ,inode=210,size=0,blksize=4096}) = 0 (0x0) >> break(0x8068000) = 0 (0x0) >> ioctl(0,TIOCGETA,0xbfbfc860) = 0 (0x0) >> write(3," Powered by FreeBSD!",28) ERR#5 'Input/output error' >> >> >> and dmesg tells me: >> >> imon: imonopen(u: 0, e: 0) - enter >> imon: successfully opened a pipe to VFD >> imon: imonopen(u: 0, e: 0) - exit: 0 (1) >> imon: imonioctl(u: 0, e: 0, cmd: 402c7413) - enter >> imon: ioctl is only implemented for IR - exit >> imon: imonwrite(u: 0, e: 0) - enter >> imon: vfd_transfer(device: imon0) - enter >> imon: transferred 0 bytes >> imon: transfer has failed >> imon: vfd_transfer() - exit >> imon: imonwrite(u: 0, e: 0) - exit: 5 >> imon: imonclose(u: 0, e: 0) - enter >> imon: user processes have all gone >> imon: imonclose(u: 0, e: 0) - exit: 0 (0) >> >> >> The good news is that I'm seeing data from the IR port at the moment. >> The bad news is that I'm not at home, so it's hard to press buttons on >> the remote remotely. :) Dmesg says: >> >> imon: imonopen(u: 0, e: 1) - enter >> imon: successfully opened a pipe to IR >> imon: imonopen(u: 0, e: 1) - exit: 0 (1) >> imon: imonintr() - data = bf ff ff ff 00 00 2e 01 >> imon: imonintr() - data = 7f ff ff ff 00 00 2e 01 >> imon: imonintr() - data = ef ff ff ff 00 00 2e 01 >> imon: imonclose(u: 0, e: 1) - enter >> imon: imonintr() - status = cancelled >> imon: user processes have all gone >> imon: imonclose(u: 0, e: 1) - exit: 0 (0) >> >> >> I'll have to do some more testing when I get home tonight. I may even >> dig around in the driver code a bit if I get some time (ick :) ). >> >> Thanks again for working on this! >> >> Alexander Popov wrote: >> >> >>> Hi, Daniel, >>> >>> Sure there will be joy in mudville :-) From the debug info I see that you have exactly the same imon model as I; so it should work. The fact that it correctly detects the device and creates nodes under >>> /dev, already indicates that at least half of the driver works. >>> >>> There are a few things that might help you: >>> >>> 1. there is a bug in my driver that prevents you from stopping LIRC daemon; so if you're testing, better remove lircd.sh from /usr/local/etc/rc.d and reboot. >>> 2. The driver is not reentrant, i.e. if one client, say LIRCd opens /dev/lirc0, then running my test script ir_test.pl will simply fail. >>> >>> I suggest to start with small - just install the driver (that you already did), then, without starting LIRCd or LCDProc, run lcd_test.pl to test VFD. This script alone should print text into the display. If not, look what the driver has printed into the console: there are a lot of debugging information, and you should see /dev/lcd0 being open, and then text written to it. >>> The same holds for ir_test.pl. What it does is simply opens /dev/lirc0 and then waits for user input. Do not press enter, but rather start pressing buttons on your remote. You should see button codes coming from the driver into the console. >>> >>> Let me know how it goes, I am sure we can get it working. >>> >>> Regards, >>> >>> Alexander. >>> >>> >>> ----- Original Message ---- >>> From: Daniel Rich <dr...@em...> >>> To: Alexander Popov <ao...@ya...> >>> Cc: lir...@li... >>> Sent: Thursday, June 5, 2008 3:37:36 AM >>> Subject: Re: LIRC on FreeBSD with a USB imon >>> >>> No joy in mudville. If I don't load the driver I can still see data >>> coming from the ugen interface, but I don't get anything from /dev/lirc0 >>> with the driver loaded using the test code or the patched lircd. It >>> does see the device, and it created /dev/lirc0 and /dev/lcd0. >>> >>> Any thoughts on debugging? Here is what I see from the driver with >>> debug enabled on boot: >>> >>> imon: USB_MATCH() - enter >>> imon: USB_MATCH() - exit: 6 >>> imon: USB_MATCH() - enter >>> imon: USB_MATCH() - exit: 6 >>> imon: USB_MATCH() - enter >>> imon: checking idVendor = 0x463, idProduct = 0xffff >>> imon: USB_MATCH() - exit: 6 >>> imon: USB_MATCH() - enter >>> imon: USB_MATCH() - exit: 6 >>> imon: USB_MATCH() - enter >>> imon: USB_MATCH() - exit: 6 >>> imon: USB_MATCH() - enter >>> imon: USB_MATCH() - exit: 6 >>> imon: USB_MATCH() - enter >>> imon: USB_MATCH() - exit: 6 >>> imon: USB_MATCH() - enter >>> imon: USB_MATCH() - exit: 6 >>> imon: USB_MATCH() - enter >>> imon: USB_MATCH() - exit: 6 >>> imon: USB_MATCH() - enter >>> imon: USB_MATCH() - exit: 6 >>> imon: USB_MATCH() - enter >>> imon: checking idVendor = 0x7b8, idProduct = 0xb02a >>> imon: USB_MATCH() - exit: 6 >>> imon: USB_MATCH() - enter >>> imon: USB_MATCH() - exit: 6 >>> imon: USB_MATCH() - enter >>> imon: checking idVendor = 0x46d, idProduct = 0xc505 >>> imon: USB_MATCH() - exit: 6 >>> imon: USB_MATCH() - enter >>> imon: checking idVendor = 0x46d, idProduct = 0xc505 >>> imon: USB_MATCH() - exit: 6 >>> imon: USB_MATCH() - enter >>> imon: USB_MATCH() - exit: 6 >>> imon: USB_MATCH() - enter >>> imon: checking idVendor = 0x15c2, idProduct = 0xffdc >>> imon: found a match, idVendor = 0x15c2, idProduct = 0xffdc >>> imon: USB_MATCH() - exit: ffffffec >>> imon: USB_MATCH() - enter >>> imon: checking idVendor = 0x15c2, idProduct = 0xffdc >>> imon: found a match, idVendor = 0x15c2, idProduct = 0xffdc >>> imon: USB_MATCH() - exit: ffffffec >>> imon0: <vendor 0x15c2 product 0xffdc, class 0/0, rev 1.10/0.00, addr 3> on uhub0 >>> imon: USB_ATTACH(device: imon0) - enter >>> imon: device supports 1 interfaces >>> imon: device supports 2 endpoints >>> imon: filter(): found endpoint nr 0 >>> imon: filter(): using endpoint 0 (addr: 0x81) for IR output >>> imon: filter(): found endpoint nr 1 >>> imon: filter(): using endpoint 1 (addr: 0x2) for VFD input >>> imon: VFD requires 6th packet: 1 >>> imon: IR signals decoded onboard: 1 >>> imon: successfully created device node for IR >>> imon: successfully created device node for VFD >>> imon: USB_ATTACH() - exit: 0 >>> >>> >>> And from usbdevs -v: >>> >>> Controller /dev/usb0: >>> addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), nVidia(0x0000), rev 1.00 >>> port 1 powered >>> port 2 powered >>> port 3 addr 2: low speed, power 98 mA, config 1, USB Receiver(0xc505), Logitech(0x046d), rev 17.00 >>> port 4 powered >>> port 5 powered >>> port 6 addr 3: low speed, power 100 mA, config 1, product 0xffdc(0xffdc), vendor 0x15c2(0x15c2), rev 0.00 >>> port 7 powered >>> port 8 powered >>> Controller /dev/usb1: >>> addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), nVidia(0x0000), rev 1.00 >>> port 1 powered >>> port 2 addr 2: high speed, self powered, config 1, USB2.0 Hub(0x0606), vendor 0x05e3(0x05e3), rev 7.02 >>> port 1 addr 3: low speed, power 20 mA, config 1, ellipse(0xffff), MGE UPS SYSTEMS(0x0463), rev 0.01 >>> port 2 addr 4: full speed, self powered, config 1, Standard USB Hub(0x3301), vendor 0x03eb(0x03eb), rev 3.00 >>> port 1 addr 5: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 >>> port 2 addr 6: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 >>> port 3 addr 7: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 >>> port 4 addr 8: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 >>> port 3 powered >>> port 4 addr 9: full speed, power 86 mA, config 1, Bluetooth USB Adapter(0xb02a), vendor 0x07b8(0x07b8), rev 5.25 >>> port 3 powered >>> port 4 powered >>> port 5 powered >>> port 6 powered >>> port 7 powered >>> port 8 powered >>> >>> >>> >>> >>> Daniel Rich wrote: >>> >>> >>> >>>> Woo hoo!!! I'll pull this down and give it at try tonight. I need to >>>> pull the server down for a bit anyway, I just got the SPDIF interface >>>> for my motherboard, I want to see if that plays better with my stereo >>>> as well. >>>> >>>> Thanks, and I'll let you know how it goes. >>>> >>>> Alexander Popov wrote: >>>> >>>> >>>> >>>>> Hi, Daniel, All, >>>>> >>>>> I have published the very first version of the IMON driver for >>>>> FreeBSD. You can find it here: >>>>> http://www.xs4all.nl/~aopopov/imon/imon.html >>>>> Please note that this is still work in progress; I would definitely >>>>> appreciate any help in testing & feedback. >>>>> >>>>> Regards, >>>>> >>>>> Alexander. >>>>> >>>>> ----- Original Message ---- >>>>> From: Daniel Rich <dr...@em...> >>>>> To: alexx8 <ao...@ya...> >>>>> Cc: lir...@li... >>>>> Sent: Wednesday, May 21, 2008 8:27:04 PM >>>>> Subject: Re: LIRC on FreeBSD with a USB imon >>>>> >>>>> Wow, that's great news! I had been considering looking at porting >>>>> the driver over, but since I haven't done any driver work in >>>>> something like 20 years (and that was System V/386 streams drivers), >>>>> I was hoping that someone else had beat me to it. :) >>>>> >>>>> If you need someone to do more testing once you have it stable, let >>>>> me know. I'm not going to have any time to play with it until after >>>>> the first of June, but I would love to give it a try after that. >>>>> >>>>> Thanks again for the reply. >>>>> >>>>> alexx8 wrote: >>>>> >>>>> >>>>> >>>>>> Hi, Dan, >>>>>> >>>>>> It's not that easy. ugen is just an universal USB driver that gets attached >>>>>> to a device if no better matching driver is found. Getting imon to work with >>>>>> ugen would be quite some effort... >>>>>> Anyway, I have been developing (porting) linux imon driver to FreeBSD in my >>>>>> spare time (not much unfortunately), and I am going to publish it in the >>>>>> coming weeks. But you can already see how it looks like on my Silversone >>>>>> case running FreeBSD 7.0: http://www.xs4all.nl/~aopopov/imon/imon.html >>>>>> >>>>>> Regards, >>>>>> >>>>>> Alex. >>>>>> >>>>>> >>>>>> Dan Rich wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> I've decided to take another stab at getting my imon IR interface >>>>>>> working on my FreeBSD server. Unfortunately, it looks like there aren't >>>>>>> any kernel-level drivers for the imon (or any other lirc interfaces), >>>>>>> however it does show up as /dev/ugen1.1. I can cat the device and I see >>>>>>> data being received. For example running od -x against /dev/ugen1, I >>>>>>> normally see "ffff ffff ffff ff2e", and when I press the mute key on the >>>>>>> remote I see "952b b795 0000 012e". This seems to be close to what I >>>>>>> would expect from the imon lirc.conf file I am trying to use, the >>>>>>> imon_pad mute should send 0x2b9595b7. However, lircd doesn't seem to >>>>>>> like this, the log file contains: lircd: Really read 2 bytes from >>>>>>> '/dev/ugen1.1', expected 3 >>>>>>> >>>>>>> Does anyone have any suggestions on where I can go from here? Are the >>>>>>> special flags I need to convince lircd that it is connected to a usb >>>>>>> serial device? Am I out of luck unless I break down >>>>>>> and write a device >>>>>>> drive (ick)? >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>> >>> >>> >> >> > > > -- Dan Rich <dr...@em...> | http://www.employees.org/~drich/ | "Step up to red alert!" "Are you sure, sir? | It means changing the bulb in the sign..." | - Red Dwarf (BBC) |
From: Daniel R. <dr...@em...> - 2008-06-02 21:32:45
Attachments:
signature.asc
|
Woo hoo!!! I'll pull this down and give it at try tonight. I need to pull the server down for a bit anyway, I just got the SPDIF interface for my motherboard, I want to see if that plays better with my stereo as well. Thanks, and I'll let you know how it goes. Alexander Popov wrote: > Hi, Daniel, All, > > I have published the very first version of the IMON driver for > FreeBSD. You can find it here: > http://www.xs4all.nl/~aopopov/imon/imon.html > Please note that this is still work in progress; I would definitely > appreciate any help in testing & feedback. > > Regards, > > Alexander. > > ----- Original Message ---- > From: Daniel Rich <dr...@em...> > To: alexx8 <ao...@ya...> > Cc: lir...@li... > Sent: Wednesday, May 21, 2008 8:27:04 PM > Subject: Re: LIRC on FreeBSD with a USB imon > > Wow, that's great news! I had been considering looking at porting the > driver over, but since I haven't done any driver work in something > like 20 years (and that was System V/386 streams drivers), I was > hoping that someone else had beat me to it. :) > > If you need someone to do more testing once you have it stable, let me > know. I'm not going to have any time to play with it until after the > first of June, but I would love to give it a try after that. > > Thanks again for the reply. > > alexx8 wrote: >> Hi, Dan, >> >> It's not that easy. ugen is just an universal USB driver that gets attached >> to a device if no better matching driver is found. Getting imon to work with >> ugen would be quite some effort... >> Anyway, I have been developing (porting) linux imon driver to FreeBSD in my >> spare time (not much unfortunately), and I am going to publish it in the >> coming weeks. But you can already see how it looks like on my Silversone >> case running FreeBSD 7.0: http://www.xs4all.nl/~aopopov/imon/imon.html >> >> Regards, >> >> Alex. >> >> >> Dan Rich wrote: >> >>> I've decided to take another stab at getting my imon IR interface >>> working on my FreeBSD server. Unfortunately, it looks like there aren't >>> any kernel-level drivers for the imon (or any other lirc interfaces), >>> however it does show up as /dev/ugen1.1. I can cat the device and I see >>> data being received. For example running od -x against /dev/ugen1, I >>> normally see "ffff ffff ffff ff2e", and when I press the mute key on the >>> remote I see "952b b795 0000 012e". This seems to be close to what I >>> would expect from the imon lirc.conf file I am trying to use, the >>> imon_pad mute should send 0x2b9595b7. However, lircd doesn't seem to >>> like this, the log file contains: lircd: Really read 2 bytes from >>> '/dev/ugen1.1', expected 3 >>> >>> Does anyone have any suggestions on where I can go from here? Are the >>> special flags I need to convince lircd that it is connected to a usb >>> serial device? Am I out of luck unless I break down >>> and write a device >>> drive (ick)? >>> >>> Thanks! >>> >>> >>> > -- Dan Rich <dr...@em...> | http://www.employees.org/~drich/ | "Step up to red alert!" "Are you sure, sir? | It means changing the bulb in the sign..." | - Red Dwarf (BBC) |
From: Daniel R. <dr...@em...> - 2008-06-05 01:37:44
Attachments:
drich.vcf
|
No joy in mudville. If I don't load the driver I can still see data coming from the ugen interface, but I don't get anything from /dev/lirc0 with the driver loaded using the test code or the patched lircd. It does see the device, and it created /dev/lirc0 and /dev/lcd0. Any thoughts on debugging? Here is what I see from the driver with debug enabled on boot: imon: USB_MATCH() - enter imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: checking idVendor = 0x463, idProduct = 0xffff imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: checking idVendor = 0x7b8, idProduct = 0xb02a imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: checking idVendor = 0x46d, idProduct = 0xc505 imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: checking idVendor = 0x46d, idProduct = 0xc505 imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: USB_MATCH() - exit: 6 imon: USB_MATCH() - enter imon: checking idVendor = 0x15c2, idProduct = 0xffdc imon: found a match, idVendor = 0x15c2, idProduct = 0xffdc imon: USB_MATCH() - exit: ffffffec imon: USB_MATCH() - enter imon: checking idVendor = 0x15c2, idProduct = 0xffdc imon: found a match, idVendor = 0x15c2, idProduct = 0xffdc imon: USB_MATCH() - exit: ffffffec imon0: <vendor 0x15c2 product 0xffdc, class 0/0, rev 1.10/0.00, addr 3> on uhub0 imon: USB_ATTACH(device: imon0) - enter imon: device supports 1 interfaces imon: device supports 2 endpoints imon: filter(): found endpoint nr 0 imon: filter(): using endpoint 0 (addr: 0x81) for IR output imon: filter(): found endpoint nr 1 imon: filter(): using endpoint 1 (addr: 0x2) for VFD input imon: VFD requires 6th packet: 1 imon: IR signals decoded onboard: 1 imon: successfully created device node for IR imon: successfully created device node for VFD imon: USB_ATTACH() - exit: 0 And from usbdevs -v: Controller /dev/usb0: addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), nVidia(0x0000), rev 1.00 port 1 powered port 2 powered port 3 addr 2: low speed, power 98 mA, config 1, USB Receiver(0xc505), Logitech(0x046d), rev 17.00 port 4 powered port 5 powered port 6 addr 3: low speed, power 100 mA, config 1, product 0xffdc(0xffdc), vendor 0x15c2(0x15c2), rev 0.00 port 7 powered port 8 powered Controller /dev/usb1: addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), nVidia(0x0000), rev 1.00 port 1 powered port 2 addr 2: high speed, self powered, config 1, USB2.0 Hub(0x0606), vendor 0x05e3(0x05e3), rev 7.02 port 1 addr 3: low speed, power 20 mA, config 1, ellipse(0xffff), MGE UPS SYSTEMS(0x0463), rev 0.01 port 2 addr 4: full speed, self powered, config 1, Standard USB Hub(0x3301), vendor 0x03eb(0x03eb), rev 3.00 port 1 addr 5: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 port 2 addr 6: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 port 3 addr 7: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 port 4 addr 8: full speed, power 100 mA, config 1, USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00 port 3 powered port 4 addr 9: full speed, power 86 mA, config 1, Bluetooth USB Adapter(0xb02a), vendor 0x07b8(0x07b8), rev 5.25 port 3 powered port 4 powered port 5 powered port 6 powered port 7 powered port 8 powered Daniel Rich wrote: > Woo hoo!!! I'll pull this down and give it at try tonight. I need to > pull the server down for a bit anyway, I just got the SPDIF interface > for my motherboard, I want to see if that plays better with my stereo > as well. > > Thanks, and I'll let you know how it goes. > > Alexander Popov wrote: >> Hi, Daniel, All, >> >> I have published the very first version of the IMON driver for >> FreeBSD. You can find it here: >> http://www.xs4all.nl/~aopopov/imon/imon.html >> Please note that this is still work in progress; I would definitely >> appreciate any help in testing & feedback. >> >> Regards, >> >> Alexander. >> >> ----- Original Message ---- >> From: Daniel Rich <dr...@em...> >> To: alexx8 <ao...@ya...> >> Cc: lir...@li... >> Sent: Wednesday, May 21, 2008 8:27:04 PM >> Subject: Re: LIRC on FreeBSD with a USB imon >> >> Wow, that's great news! I had been considering looking at porting >> the driver over, but since I haven't done any driver work in >> something like 20 years (and that was System V/386 streams drivers), >> I was hoping that someone else had beat me to it. :) >> >> If you need someone to do more testing once you have it stable, let >> me know. I'm not going to have any time to play with it until after >> the first of June, but I would love to give it a try after that. >> >> Thanks again for the reply. >> >> alexx8 wrote: >>> Hi, Dan, >>> >>> It's not that easy. ugen is just an universal USB driver that gets attached >>> to a device if no better matching driver is found. Getting imon to work with >>> ugen would be quite some effort... >>> Anyway, I have been developing (porting) linux imon driver to FreeBSD in my >>> spare time (not much unfortunately), and I am going to publish it in the >>> coming weeks. But you can already see how it looks like on my Silversone >>> case running FreeBSD 7.0: http://www.xs4all.nl/~aopopov/imon/imon.html >>> >>> Regards, >>> >>> Alex. >>> >>> >>> Dan Rich wrote: >>> >>>> I've decided to take another stab at getting my imon IR interface >>>> working on my FreeBSD server. Unfortunately, it looks like there aren't >>>> any kernel-level drivers for the imon (or any other lirc interfaces), >>>> however it does show up as /dev/ugen1.1. I can cat the device and I see >>>> data being received. For example running od -x against /dev/ugen1, I >>>> normally see "ffff ffff ffff ff2e", and when I press the mute key on the >>>> remote I see "952b b795 0000 012e". This seems to be close to what I >>>> would expect from the imon lirc.conf file I am trying to use, the >>>> imon_pad mute should send 0x2b9595b7. However, lircd doesn't seem to >>>> like this, the log file contains: lircd: Really read 2 bytes from >>>> '/dev/ugen1.1', expected 3 >>>> >>>> Does anyone have any suggestions on where I can go from here? Are the >>>> special flags I need to convince lircd that it is connected to a usb >>>> serial device? Am I out of luck unless I break down >>>> and write a device >>>> drive (ick)? >>>> >>>> Thanks! >>>> >>>> -- Dan Rich <dr...@em...> | http://www.employees.org/~drich/ | "Step up to red alert!" "Are you sure, sir? | It means changing the bulb in the sign..." | - Red Dwarf (BBC) |