From: Enrico S. <enr...@gm...> - 2003-11-07 20:22:22
|
Hello Paul, Yeah, I had two versions of lirc on my system, but removing all and reinstalling did nor resolve the problem :-( The output of strace again: >>> gettimeofday({1068236441, 372085}, NULL) = 0 select(8, [4 6 7], NULL, NULL, NULL) = 1 (in [7]) gettimeofday({1068236441, 372178}, NULL) = 0 read(7, 0xbffff4c0, 5) = -1 EINVAL (Invalid argument) time([1068236441]) = 1068236441 write(2, "lircd 0.7.0pre1: ", 17) = 17 write(5, "Nov 7 21:20:41 amd lircd 0.7.0p"..., 79) = 79 write(2, "reading in mode LIRC_MODE_LIRCCO"..., 41) = 41 write(2, ptrace: umoven: Input/output error 0x40159f27, 1) = 1 <<< Thanks Enrico Am Freitag, 7. November 2003 00:43 schrieb Paul Miller: > Are you mixing lirc cvs and version 0.6.6? It sure looks like it. Please > uninstall version 0.6.6 before trying the cvs version. > > -Paul > > > Hi Paul again, > > > > I am using now the current cvs version. It works as far as I do not get > > any > > error message from irw and I could start it again and again - Thanks. The > > contra is that lircd has about 99% cpu load... and irw does not print the > > codes to stdout. irrecord gives the following message: > > > > irrecord: reading in mode LIRC_MODE_LIRCCODE failed > > > > the output of strace of lircd (started with -n) when hanging in the loop > > gives: > > > > gettimeofday({1068155794, 292700}, NULL) = 0 > > select(8, [4 6 7], NULL, NULL, NULL) = 1 (in [7]) > > gettimeofday({1068155794, 292794}, NULL) = 0 > > read(7, 0xbffff4d0, 5) = -1 EINVAL (Invalid argument) > > time([1068155794]) = 1068155794 > > write(2, "lircd 0.6.6: ", 13) = 13 > > write(5, "Nov 6 22:56:34 amd lircd 0.6.6:"..., 75) = 75 > > write(2, "reading in mode LIRC_MODE_LIRCCO"..., 41) = 41 > > write(2, ptrace: umoven: Input/output error > > 0x40159f27, 1) = 1 > > <<< > > and the following on stdout: > > > > lircd 0.6.6: reading in mode LIRC_MODE_LIRCCODE failed > > <<< > > > > Thanks > > > > Enrico > > > > Am Donnerstag, 6. November 2003 13:37 schrieb Enrico Schnepel: > >> Hi Paul, > >> > >> The line 259, cvs v1.7 is the place where I put > >> > >> if ((urb->actual_length != 4) && (urb->actual_length != 5)) return; > >> > >> The question is how to implement this check using a more generic Min/Max > >> if-clause. > >> I am thinking about a combination with the table usb_remote_id_table. > >> if we have the index of the current device in the struct. we could use > >> this > >> index as an index into a second table containing the min/max-values. > >> If we do not have the index we may use a table containing the min/max > >> values and as index the minor usb device id if it is stored somewhere. > >> for most devices the pair would be min 4 / max 4 but for the device > >> 0x0005 > >> it would be min 4 / max 5. > >> > >> I will test the new version this evening. > >> > >> Thanks > >> > >> Enrico > >> > >> > Hi Enrico, > >> > > >> > Please try updating to the latest cvs again (delete your old file > >> > first). I think I have the -EIO problem fixed. > >> > > >> > Also, how did you change the code to support both 4 and 5 bytes? The > >> > only place it actually compares the bytes received is in > >> > usb_remote_irq() with "if (urb->actual_length != ir->p->code_length/8) > >> > return" (line 259, cvs v1.7). > >> > > >> > -Paul > >> > > >> > On Wednesday 05 November 2003 2:44 pm, you wrote: > >> > > Hello Paul, > >> > > > >> > > I am using already the current CVS version of lirc, but i changed > >> > >> the > >> > >> > > code to > >> > > >> > support both 4 and 5 bytes in this if-clause. > >> > > >> > > Using the modified if-clause i could use lirc - but only one time. > >> > > > >> > > All output is made with CONFIG_USB_DEBUG enabled. > >> > > > >> > > When starting irw and pressing some keys on the remote I am getting > >> > > the > >> > > >> > following syslog output: > >> > > Nov 5 20:50:27 amd kernel: lirc_usb[2]: set use inc > >> > > Nov 5 20:50:27 amd kernel: lirc_usb[2]: usb irq called > >> > > ... > >> > > Nov 5 20:50:51 amd kernel: lirc_usb[2]: usb irq called > >> > > Nov 5 20:51:05 amd kernel: lirc_usb[2]: set use dec > >> > > <<< > >> > > irw does report the correct codes. > >> > > > >> > > after terminating irw and starting it a second time I am getting the > >> > > following > >> > > >> > output: > >> > > Nov 5 20:51:19 amd kernel: lirc_usb[2]: set use inc > >> > > Nov 5 20:51:19 amd kernel: usb-uhci.c: ENXIO 44408280, flags 0, urb > >> > > ca0d5c64, > >> > > >> > burb ca0d5c64 > >> > > >> > > Nov 5 20:51:19 amd kernel: lirc_usb[2]: open result = -E10 error > >> > > submitting > >> > > >> > urb > >> > > >> > > <<< > >> > > irw terminates without a message. > >> > > > >> > > starting irw a third time results in a > >> > > > >> > > > >> > > > >> > > connect: Connection refused > >> > > <<< > >> > > and no message on syslog. > >> > > > >> > > after restarting the usb stack an doing the same againg with > >> > >> irrecord > >> > >> > > i am > >> > > >> > getting the following output: > >> > > Nov 5 20:56:45 amd kernel: lirc_usb[2]: set use inc > >> > > Nov 5 20:50:27 amd kernel: lirc_usb[2]: usb irq called > >> > > ... > >> > > Nov 5 20:50:51 amd kernel: lirc_usb[2]: usb irq called > >> > > Nov 5 20:57:15 amd kernel: lirc_usb[2]: set use dec > >> > > Nov 5 20:57:15 amd kernel: lirc_usb[2]: set use inc > >> > > Nov 5 20:57:15 amd kernel: usb-uhci.c: ENXIO 44408280, flags 0, urb > >> > > c388ae84, > >> > > >> > burb c388ae84 > >> > > >> > > Nov 5 20:57:15 amd kernel: lirc_usb[2]: open result = -E10 error > >> > > submitting > >> > > >> > urb > >> > > >> > > <<< > >> > > irrecord prints the following message: > >> > > > >> > > > >> > > > >> > > irrecord: could not open /dev/lirc > >> > > irrecord: default_init(): Input/output error > >> > > irrecord: could not reset hardware. > >> > > <<< > >> > > It seems to me that irrecord opens a new lirc session after closing > >> > > the old > >> > > >> > one... > >> > > >> > > with the original if-clause... > >> > > > >> > > changing bytes_in_key did not work. > >> > > > >> > > initializing bytes_in_key with 4 results in: > >> > > ir->p->code_length==32 > >> > > with 5 in: > >> > > ir->p->code_length==40 > >> > > in combination with urb->actual_length the result is that in the > >> > > first case > >> > > >> > only 4-byte codes are accepted. in the second case - > >> > > >> > > instead of accepting only 5 byte long codes - the driver could not > >> > >> be > >> > >> > > initialised ... but this could be an other problem. > >> > > > >> > > I am leaving the modified if-clause but the > >> > > "only-one-time-use"-problem is not > >> > > >> > solved. > >> > > >> > > I think there should be a better solution for the if-clause because > >> > > my > >> > > >> > modified one is very rigid. I don't know whether it is possible > >> > > >> > > to implement the "possible counts of bits/bytes" in the > >> > > usb_remote_id_table. > >> > > The syslog shows the following when initialising the usb stack > >> > > (CONFIG_USB_DEBUG enabled): > >> > > > >> > > > >> > > > >> > > Nov 5 21:16:28 amd kernel: usb.c: registered new driver usbdevfs > >> > > Nov 5 21:16:28 amd kernel: usb.c: registered new driver hub > >> > > Nov 5 21:16:28 amd kernel: usb-uhci.c: $Revision: 1.275 $ time > >> > > 12:38:59 Oct > >> > > >> > 3 2003 > >> > > >> > > Nov 5 21:16:28 amd kernel: usb-uhci.c: High bandwidth mode enabled > >> > > Nov 5 21:16:28 amd kernel: usb-uhci.c: USB UHCI at I/O 0xd800, IRQ > >> > > 11 > >> > > >> > Nov 5 21:16:28 amd kernel: usb-uhci.c: Detected 2 ports > >> > > >> > > Nov 5 21:16:28 amd kernel: usb.c: new USB bus registered, assigned > >> > > bus number > >> > > >> > 1 > >> > > >> > > Nov 5 21:16:28 amd kernel: hub.c: USB hub found > >> > > Nov 5 21:16:28 amd kernel: hub.c: 2 ports detected > >> > > Nov 5 21:16:28 amd kernel: usb-uhci.c: USB UHCI at I/O 0xdc00, IRQ > >> > > 11 > >> > > >> > Nov 5 21:16:28 amd kernel: usb-uhci.c: Detected 2 ports > >> > > >> > > Nov 5 21:16:28 amd kernel: usb.c: new USB bus registered, assigned > >> > > bus number > >> > > >> > 2 > >> > > >> > > Nov 5 21:16:28 amd kernel: hub.c: USB hub found > >> > > Nov 5 21:16:28 amd kernel: hub.c: 2 ports detected > >> > > Nov 5 21:16:28 amd kernel: usb-uhci.c: v1.275:USB Universal Host > >> > > Controller > >> > > >> > Interface driver > >> > > >> > > Nov 5 21:16:28 amd /etc/hotplug/usb.rc[10185]: loaded HCD: usb-uhci > >> > > Nov 5 21:16:28 amd kernel: uhci.c: USB Universal Host Controller > >> > > Interface > >> > > >> > driver v1.1 > >> > > >> > > Nov 5 21:16:28 amd kernel: hub.c: new USB device 00:07.2-2, > >> > >> assigned > >> > >> > > address > >> > > >> > 2 > >> > > >> > > Nov 5 21:16:29 amd kernel: usb.c: USB device 2 (vend/prod > >> > >> 0xbc7/0x5) > >> > >> > > is not > >> > > >> > claimed by any active driver. > >> > > >> > > Nov 5 21:16:38 amd kernel: lirc_dev: IR Remote Control driver > >> > > registered, at > >> > > >> > major 61 > >> > > >> > > Nov 5 21:16:38 amd kernel: > >> > > Nov 5 21:16:38 amd kernel: lirc_usb: USB remote driver for LIRC > >> > > v0.1 > >> > > >> > Nov 5 21:16:38 amd kernel: lirc_usb: Paul Miller > >> > > >> > > <pmi...@us...> > >> > > Nov 5 21:16:38 amd kernel: lirc_usb: debug mode enabled > >> > > Nov 5 21:16:38 amd kernel: usb.c: registered new driver lirc_usb > >> > > Nov 5 21:16:38 amd kernel: lirc_usb: usb probe called > >> > > Nov 5 21:16:38 amd kernel: usb-uhci.c: interrupt, status 3, frame# > >> > > 1482 > >> > > >> > Nov 5 21:16:38 amd kernel: lirc_dev: > >> > > lirc_register_plugin:sample_rate: 0 Nov 5 21:16:38 amd kernel: > >> > > lirc_usb[2]: X10 Wireless Technology Inc USB Receiver on usb1:2.0 > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: maxp = 5, buf_len = 8 > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: send called (0x8004) > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: send called (0x8007) > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called > >> > > Nov 5 21:16:38 amd insmod: Using > >> > > /lib/modules/2.4.20-4GB/misc/lirc_dev.o > >> > > >> > Nov 5 21:16:38 amd insmod: > >> > > Symbol version prefix '' > >> > > Nov 5 21:16:38 amd insmod: Using > >> > > /lib/modules/2.4.20-4GB/misc/lirc_atiusb.o > >> > > >> > <<< > >> > > >> > > thanks a lot > >> > > > >> > > Enrico > >> > > > >> > > Am Dienstag, 4. November 2003 15:37 schrieb Paul Miller: > >> > > > Enrico, > >> > > > Could you please try using the latest CVS version of LIRC? The > >> > > > check you > >> > > >> > mentioned for urb->actual_length is not in the latest > >> > > >> > > > cvs version. Also try changing "bytes_in_key" to 5 (line 323) if > >> > > > the default of 4 doesn't work. > >> > > > > >> > > > Please send me the full debug output (load the driver w/ debug=1) > >> > > > and > >> > > >> > /proc/bus/usb/devices. > >> > > >> > > > Thanks, > >> > > > -Paul > >> > > > > >> > > > > Hello, > >> > > > > > >> > > > > I have an Q-Sonic Master Remote PC / TV from the german > >> > > > > distributor Pearl > >> > > >> > Agency. The USB Receiver gives the atached > >> > > >> > > > > usbview output. The file /proc/bus/usb/devices is also atached. > >> > > > > > >> > > > > I have the problem that my some keys have 5 bytes and some 4 > >> > > > > bytes > >> > > >> > (urb->actual_length) in usb_remote_irq. > >> > > >> > > > > the if clause testing these variable fails therefore. > >> > > > > but an > >> > > > > > >> > > > > if ((urb->actual_length != 4) && (urb->actual_length != > >> > > > > 5)) > >> > > >> > return; > >> > > >> > > > > << > >> > > > > does also not work. this seems not the only problem. > >> > > > > > >> > > > > The second problem is that i have to reload the complete usb > >> > > > > stack after > >> > > >> > every > >> > > >> > > > > time a program used lirc. This happens also when using irrecord. > >> > > > > The syslog says: > >> > > > > > >> > > > > lirc_unregister_plugin:minor (0) device not > >> > > > > registered!lirc_usb[2]: > >> > > >> > didn't free resources > >> > > >> > > > > << > >> > > > > > >> > > > > Thanks a lot > >> > > > > > >> > > > > Enrico > >> > > > >> > > -- > >> > > "Der Mensch, der bereit ist, seine Freiheit aufzugeben, um > >> > > Sicherheit zu gewinnen, wird beides verlieren." > >> > > - - Benjamin Franklin > > > > -- > > "Der Mensch, der bereit ist, seine Freiheit aufzugeben, um > > Sicherheit zu gewinnen, wird beides verlieren." > > - - Benjamin Franklin > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SF.net Giveback Program. > > Does SourceForge.net help you be more productive? Does it > > help you create better code? SHARE THE LOVE, and help us help > > YOU! Click Here: http://sourceforge.net/donate/ > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ -- "Der Mensch, der bereit ist, seine Freiheit aufzugeben, um Sicherheit zu gewinnen, wird beides verlieren." - - Benjamin Franklin |