From: David K. <fo...@gm...> - 2010-02-24 18:04:16
Attachments:
mozart-sx.txt
|
Hello, I have a HTPC in a Tt Mozart SX case - there's a remote with a directional knob and a front panel VFD + buttons. Everything (remote, VFD) has been working perfectly since I bought it like a year ago, but now I'd like to use the front buttons too. It seems to me like it's not supported or perhaps I didn't connect all the wires when installing? I found just one internal USB connector coming from the case front, though. Now I find those front panel buttons would be very useful in some situations. I'm attaching a lsusb -v output for the SoundGraph device. Perhaps somebody will see something. Are front panel buttons supported? If so, how does the driver forward those events? I stopped using the remote in favour of PS3 BD remote, because it works better from a distance, but when I configured the original remote some time ago, the LIRC device only returned remote button events, not from the front panel. Thanks for any hints! -- David Kubicek |
From: Jarod W. <ja...@wi...> - 2010-02-25 19:31:29
|
On Wed, Feb 24, 2010 at 1:04 PM, David Kubicek <fo...@gm...> wrote: > Hello, > > I have a HTPC in a Tt Mozart SX case - there's a remote with a directional > knob and a front panel VFD + buttons. Everything (remote, VFD) has been > working perfectly since I bought it like a year ago, but now I'd like to use > the front buttons too. It seems to me like it's not supported or perhaps I > didn't connect all the wires when installing? I found just one internal USB > connector coming from the case front, though. > > Now I find those front panel buttons would be very useful in some > situations. > > I'm attaching a lsusb -v output for the SoundGraph device. Perhaps somebody > will see something. Are front panel buttons supported? If so, how does the > driver forward those events? > > I stopped using the remote in favour of PS3 BD remote, because it works > better from a distance, but when I configured the original remote some time > ago, the LIRC device only returned remote button events, not from the front > panel. > > Thanks for any hints! Define "some time ago" more precisely... The 0036 device *should* be fully functional these days (just one usb cable for everything is correct). -- Jarod Wilson ja...@wi... |
From: David K. <fo...@gm...> - 2010-02-25 21:13:05
Attachments:
lircd-imon.conf
|
On 02/25/2010 08:29 PM, Jarod Wilson wrote: > On Wed, Feb 24, 2010 at 1:04 PM, David Kubicek<fo...@gm...> wrote: > > Define "some time ago" more precisely... The 0036 device *should* be > fully functional these days (just one usb cable for everything is > correct). > I wasn't sure how thoroughly I tested it at the beginning, so I tried again and found the LIRC config I used previously just had wrong codes for the front panel buttons. I used irrecord to capture correct values and it works now. There is still one issue, though. I never used LIRC before my HTPC so I'm not really familiar with concepts like gap, toggle mask and stuff. The front panel is routed into /dev/input by a dedicated lircd instance to keep it separate from regular LIRC apps, in case those go tits up. You know, to have a "backup" control independent from my usual apps. I use uinput, because I don't need modes and adv. LIRC config for this panel. The thing is when I push any button on the panel, I get a stream of events from LIRC. Not just one press event. As soon as I push, events come flooding in until I release. See my lircd.conf. Which options should I try to change to get the usual one event per push behaviour? Thanks! -- David Kubicek |
From: Jarod W. <ja...@wi...> - 2010-02-26 03:55:50
|
On Thu, Feb 25, 2010 at 4:12 PM, David Kubicek <fo...@gm...> wrote: > On 02/25/2010 08:29 PM, Jarod Wilson wrote: >> >> On Wed, Feb 24, 2010 at 1:04 PM, David Kubicek<fo...@gm...> wrote: >> >> Define "some time ago" more precisely... The 0036 device *should* be >> fully functional these days (just one usb cable for everything is >> correct). >> > > I wasn't sure how thoroughly I tested it at the beginning, so I tried again > and found the LIRC config I used previously just had wrong codes for the > front panel buttons. > > I used irrecord to capture correct values and it works now. There is still > one issue, though. I never used LIRC before my HTPC so I'm not really > familiar with concepts like gap, toggle mask and stuff. > > The front panel is routed into /dev/input by a dedicated lircd instance to > keep it separate from regular LIRC apps, in case those go tits up. You know, > to have a "backup" control independent from my usual apps. I use uinput, > because I don't need modes and adv. LIRC config for this panel. > > The thing is when I push any button on the panel, I get a stream of events > from LIRC. Not just one press event. As soon as I push, events come flooding > in until I release. See my lircd.conf. > > Which options should I try to change to get the usual one event per push > behaviour? Use http://lirc.sourceforge.net/remotes/imon/lircd.conf.imon-antec-veris instead. -- Jarod Wilson ja...@wi... |
From: David K. <fo...@gm...> - 2010-02-26 16:28:11
|
On 02/26/2010 04:55 AM, Jarod Wilson wrote: > On Thu, Feb 25, 2010 at 4:12 PM, David Kubicek<fo...@gm...> wrote: >> The thing is when I push any button on the panel, I get a stream of events >> from LIRC. Not just one press event. As soon as I push, events come flooding >> in until I release. See my lircd.conf. >> >> Which options should I try to change to get the usual one event per push >> behaviour? > > Use http://lirc.sourceforge.net/remotes/imon/lircd.conf.imon-antec-veris > instead. > Thank you. The issue remains however and some front panel buttons don't work at all now. Check out irw output - first pressing the remote, then 7 front panel buttons (except Power & Reset). As you can see, only 4 buttons show up (Mute, VolUp, VolDown don't work now). What do you think? irw output (*short* single presses): 299195b700000201 00 KEY_AUDIO Antec_Veris_RM200 2b8515b700000201 00 KEY_VIDEO Antec_Veris_RM200 0200002a00000201 00 KEY_BACKSPACE Antec_Veris_RM200 0100800000000201 00 KEY_UP Antec_Veris_RM200 01007f0000000201 00 KEY_DOWN Antec_Veris_RM200 0200002a00000201 00 KEY_BACKSPACE Antec_Veris_RM200 00000000050002ee 00 KEY_PREVIOUS Antec_Veris_Premiere 00000000050002ee 01 KEY_PREVIOUS Antec_Veris_Premiere 00000000050002ee 02 KEY_PREVIOUS Antec_Veris_Premiere 00000000050002ee 03 KEY_PREVIOUS Antec_Veris_Premiere 00000000050002ee 04 KEY_PREVIOUS Antec_Veris_Premiere 00000000060002ee 00 KEY_NEXT Antec_Veris_Premiere 00000000060002ee 01 KEY_NEXT Antec_Veris_Premiere 00000000060002ee 02 KEY_NEXT Antec_Veris_Premiere 00000000060002ee 03 KEY_NEXT Antec_Veris_Premiere 00000000040002ee 00 KEY_STOP Antec_Veris_Premiere 00000000040002ee 01 KEY_STOP Antec_Veris_Premiere 00000000040002ee 02 KEY_STOP Antec_Veris_Premiere 00000000040002ee 03 KEY_STOP Antec_Veris_Premiere 00000000040002ee 04 KEY_STOP Antec_Veris_Premiere 000000003c0002ee 00 KEY_PLAYPAUSE Antec_Veris_Premiere 000000003c0002ee 01 KEY_PLAYPAUSE Antec_Veris_Premiere 000000003c0002ee 02 KEY_PLAYPAUSE Antec_Veris_Premiere 000000003c0002ee 03 KEY_PLAYPAUSE Antec_Veris_Premiere 000000003c0002ee 04 KEY_PLAYPAUSE Antec_Veris_Premiere 000000003c0002ee 05 KEY_PLAYPAUSE Antec_Veris_Premiere Case photo: http://www.repteil.de/data/tinymce/uploaded/shop/produkte/thermaltacke_mozart_sx_sb.jpg -- David Kubicek |
From: Jarod W. <ja...@wi...> - 2010-02-26 21:44:18
|
On Fri, Feb 26, 2010 at 11:27 AM, David Kubicek <fo...@gm...> wrote: > On 02/26/2010 04:55 AM, Jarod Wilson wrote: >> >> On Thu, Feb 25, 2010 at 4:12 PM, David Kubicek<fo...@gm...> wrote: >>> >>> The thing is when I push any button on the panel, I get a stream of >>> events >>> from LIRC. Not just one press event. As soon as I push, events come >>> flooding >>> in until I release. See my lircd.conf. >>> >>> Which options should I try to change to get the usual one event per push >>> behaviour? >> >> Use http://lirc.sourceforge.net/remotes/imon/lircd.conf.imon-antec-veris >> instead. >> > > Thank you. > > The issue remains however and some front panel buttons don't work at all > now. Check out irw output - first pressing the remote, then 7 front panel > buttons (except Power & Reset). As you can see, only 4 buttons show up > (Mute, VolUp, VolDown don't work now). One of these days, I'm going to consolidate things down to just one config file that covers all devices... (maybe two). Seems we're missing some values from your device though. SoundGraph keeps having different displays translate to different codes. Sigh. > What do you think? > > irw output (*short* single presses): > > 299195b700000201 00 KEY_AUDIO Antec_Veris_RM200 > 2b8515b700000201 00 KEY_VIDEO Antec_Veris_RM200 > 0200002a00000201 00 KEY_BACKSPACE Antec_Veris_RM200 > 0100800000000201 00 KEY_UP Antec_Veris_RM200 > 01007f0000000201 00 KEY_DOWN Antec_Veris_RM200 > 0200002a00000201 00 KEY_BACKSPACE Antec_Veris_RM200 > 00000000050002ee 00 KEY_PREVIOUS Antec_Veris_Premiere > 00000000050002ee 01 KEY_PREVIOUS Antec_Veris_Premiere > 00000000050002ee 02 KEY_PREVIOUS Antec_Veris_Premiere > 00000000050002ee 03 KEY_PREVIOUS Antec_Veris_Premiere > 00000000050002ee 04 KEY_PREVIOUS Antec_Veris_Premiere > 00000000060002ee 00 KEY_NEXT Antec_Veris_Premiere > 00000000060002ee 01 KEY_NEXT Antec_Veris_Premiere > 00000000060002ee 02 KEY_NEXT Antec_Veris_Premiere > 00000000060002ee 03 KEY_NEXT Antec_Veris_Premiere > 00000000040002ee 00 KEY_STOP Antec_Veris_Premiere > 00000000040002ee 01 KEY_STOP Antec_Veris_Premiere > 00000000040002ee 02 KEY_STOP Antec_Veris_Premiere > 00000000040002ee 03 KEY_STOP Antec_Veris_Premiere > 00000000040002ee 04 KEY_STOP Antec_Veris_Premiere > 000000003c0002ee 00 KEY_PLAYPAUSE Antec_Veris_Premiere > 000000003c0002ee 01 KEY_PLAYPAUSE Antec_Veris_Premiere > 000000003c0002ee 02 KEY_PLAYPAUSE Antec_Veris_Premiere > 000000003c0002ee 03 KEY_PLAYPAUSE Antec_Veris_Premiere > 000000003c0002ee 04 KEY_PLAYPAUSE Antec_Veris_Premiere > 000000003c0002ee 05 KEY_PLAYPAUSE Antec_Veris_Premiere That all looks perfectly normal, they're clearly labeled as repeats. (the incrementing value in column two). Just suppress repeats in your lircrc and/or run lircd with the -R (--repeat-max) X option to limit things to X repeats. I use the lircrc repeat suppression myself. -- Jarod Wilson ja...@wi... |
From: David K. <fo...@gm...> - 2010-02-27 01:22:42
|
On 02/26/2010 10:44 PM, Jarod Wilson wrote: > That all looks perfectly normal, they're clearly labeled as repeats. > (the incrementing value in column two). Just suppress repeats in your > lircrc and/or run lircd with the -R (--repeat-max) X option to limit > things to X repeats. I use the lircrc repeat suppression myself. > OK then. I used repeat limits with that remote anyway, it was awfully unpredictable. Looks like these buttons are a bit dodgy too. :) I just thought this kind of behaviour could be smoothed out by a lircd config. Granted, physically the panel is really sending all those events so it's not really an issue of LIRC. Anyway, thanks for those tips! BTW, I had to make a tiny patch for lircrcd, it was segfaulting on me because of unhandled NULL dereference in CODE handler (triggered when client didn't send \n). I'm using kind of complex modes and really needed the daemon: Index: lircrcd.c =================================================================== RCS file: /cvsroot/lirc/lirc/tools/lircrcd.c,v retrieving revision 5.4 diff -r5.4 lircrcd.c 447a448,451 > if(arguments == NULL) > { > return send_error(fd, message, "protocol error\n"); > } The source application (mythtv) was using LIRC "template" lirc_client.c, the newline character is still missing in CVS. I talked about it with them they accepted it as a bug, but asked me to let you know to fix this "in the source": Index: lirc_client.c =================================================================== RCS file: /cvsroot/lirc/lirc/tools/lirc_client.c,v retrieving revision 5.29 diff -r5.29 lirc_client.c 1624c1624 < sprintf(command, "CODE %s", code); --- > sprintf(command, "CODE %s\n", code); Here's my original post in mythtv-dev: http://www.gossamer-threads.com/lists/mythtv/dev/422800 Cheers! -- David Kubicek |
From: <li...@ba...> - 2010-02-27 08:17:50
|
Hi! David Kubicek "fo...@gm..." wrote: [...] > BTW, I had to make a tiny patch for lircrcd, it was segfaulting on me > because of unhandled NULL dereference in CODE handler (triggered when > client didn't send \n). I'm using kind of complex modes and really > needed the daemon: > > Index: lircrcd.c > =================================================================== > RCS file: /cvsroot/lirc/lirc/tools/lircrcd.c,v > retrieving revision 5.4 > diff -r5.4 lircrcd.c > 447a448,451 >> if(arguments == NULL) >> { >> return send_error(fd, message, "protocol error\n"); >> } Ok. > The source application (mythtv) was using LIRC "template" lirc_client.c, > the newline character is still missing in CVS. I talked about it with > them they accepted it as a bug, but asked me to let you know to fix this > "in the source": > > Index: lirc_client.c > =================================================================== > RCS file: /cvsroot/lirc/lirc/tools/lirc_client.c,v > retrieving revision 5.29 > diff -r5.29 lirc_client.c > 1624c1624 > < sprintf(command, "CODE %s", code); > -+- >> sprintf(command, "CODE %s\n", code); This is wrong. code already contains the \n. > Here's my original post in mythtv-dev: > http://www.gossamer-threads.com/lists/mythtv/dev/422800 Why anyone would want to have it's own lirc_client.c? Christoph |
From: David K. <fo...@gm...> - 2010-02-27 13:02:57
|
On 02/27/2010 09:16 AM, Christoph Bartelmus wrote: > Hi! > > David Kubicek "fo...@gm..." wrote: > [...] >> Index: lircrcd.c >> =================================================================== >> RCS file: /cvsroot/lirc/lirc/tools/lircrcd.c,v >> retrieving revision 5.4 >> diff -r5.4 lircrcd.c >> 447a448,451 >>> if(arguments == NULL) >>> { >>> return send_error(fd, message, "protocol error\n"); >>> } > > Ok. > Thanks. >> Index: lirc_client.c >> =================================================================== >> RCS file: /cvsroot/lirc/lirc/tools/lirc_client.c,v >> retrieving revision 5.29 >> diff -r5.29 lirc_client.c >> 1624c1624 >> < sprintf(command, "CODE %s", code); >> -+- >>> sprintf(command, "CODE %s\n", code); > > This is wrong. code already contains the \n. > >> Here's my original post in mythtv-dev: >> http://www.gossamer-threads.com/lists/mythtv/dev/422800 > > Why anyone would want to have it's own lirc_client.c? > Exactly, but that's how it is. So you say the string in "code" already has the newline... How come their lirc_client wreaks havoc without this newline in FMT - could it be getting lost or something? One thing is for sure, lircrcd exits (gracefully) unless there's a newline in this FMT. It's not just me, I found this ticket in myth trac: http://svn.mythtv.org/trac/ticket/7653 Without it, I send one event from myth and lircrcd is gone. Gdb shows it just left the loop and exitted. If I add the newline, everything works perfectly. If you're right that this sprintf always leaves a newline, then there must be another bug in lircrcd. I only analysed the NULL dereference, because the daemon stopped exitting after I added \n to CODE in myth client. I could check this out if you want... Keep up the good work! -- David Kubicek |
From: <li...@ba...> - 2010-02-28 08:19:58
|
Hi! David Kubicek "fo...@gm..." wrote: > On 02/27/2010 09:16 AM, Christoph Bartelmus wrote: >>> < sprintf(command, "CODE %s", code); >>> -+- >>>> sprintf(command, "CODE %s\n", code); >> >> This is wrong. code already contains the \n. >> >>> Here's my original post in mythtv-dev: >>> http://www.gossamer-threads.com/lists/mythtv/dev/422800 >> >> Why anyone would want to have it's own lirc_client.c? >> > Exactly, but that's how it is. So you say the string in "code" already > has the newline... How come their lirc_client wreaks havoc without this > newline in FMT - could it be getting lost or something? The problem is that they don't use lirc_nextcode() in their lirc.cpp but have their own read function, which throws away the newline. lirc_client is the wrong place to add it. lirc_code2char simply expects the newline still to be in the code string. Christoph |
From: David K. <fo...@gm...> - 2010-02-28 14:20:21
|
On 02/28/2010 09:18 AM, Christoph Bartelmus wrote: >> Exactly, but that's how it is. So you say the string in "code" already >> has the newline... How come their lirc_client wreaks havoc without this >> newline in FMT - could it be getting lost or something? > > The problem is that they don't use lirc_nextcode() in their lirc.cpp but > have their own read function, which throws away the newline. > lirc_client is the wrong place to add it. > lirc_code2char simply expects the newline still to be in the code string. > Right, so that's it! It looked to me like the newline was really missing. I'll tell them to add the newline in lirc_code2char despite it not being in original lirc_client. I realized later that my explanation of the the NULL dereference was wrong. I forgot the details since I debugged it. It is triggerend by an "empty" CODE, not a missing newline. Myth has a second issue where it sends just "CODE " under certain circumstances and this made lircrcd segfault - so it's not related to the newline. Thanks for cooperation. -- David Kubicek |
From: <li...@ba...> - 2010-02-27 08:17:50
|
Hi! Jarod Wilson "ja...@wi..." wrote: [...] > That all looks perfectly normal, they're clearly labeled as repeats. > (the incrementing value in column two). Just suppress repeats in your > lircrc and/or run lircd with the -R (--repeat-max) X option to limit > things to X repeats. I use the lircrc repeat suppression myself. --repeat-max only affects the transmit path. 0.8.7 will support a suppress_repeat header entry in lircd.conf that will suppress the first X repeats. Christoph |