From: vika <vik...@ya...> - 2008-10-28 15:56:30
|
> Hi, > > It's 5.25" bay VDF+IR called Antec Multimedia Station or Antec Veris > Elite. > By the looks and features it's almost identical with the retail iMON > VFD but it has different device id. > > Bus 004 Device 002: ID 15c2:0044 SoundGraph Inc. > > I've tried to add the device id to the Lirc source but no succes so > far. I'm no pro in this matter. > > Is there any info i can give to you so that you could add this > device to the future releases? Do you know if it is a VFD for sure, or if it is an LCD? The LCD model for mine - 15c2:0038 looks like this: http://codeka.com/blogs/media/imonlcd-0.3.jpg (see the little icons and such around the display) There are some somewhat outdated but still valid instructions for the 15c2:0038 device here that may be of assistance to you: http://mythtvblog.blogspot.com/2008/04/getting-imon-0038-lcd-working-with-lirc.html Another way to see if it is the LCD is to look at the endpoints defined on the device: run "lsusb -d 15c2:0044 -v | grep bEndpoint" and if the output that has 2 lines that are labeled "IN" like this: lsusb -d 15c2:0038 -v | grep bEndpoint bEndpointAddress 0x81 EP 1 IN bEndpointAddress 0x82 EP 2 IN Then it is most likely that you have an LCD device. STEP 1: Make sure that the HID driver isn't claiming the device. First, make sure that the USB HID driver isn't taking control of the device. The easiest way to do this is to use usbfs: mount -t usbfs none /proc/bus/usb cat /proc/bus/usb/devices And look for the device. If it says driver: usbhid - you need to first get the usbhid driver to ignore the device (see that blog post for instructions on this) STEP 2: Test that you can drive the device with arbitrary input There is a some sample C code someone wrote to help test the reverse- engineering of the protocol called 'imon_poke' - that you can compile and run to try to see if you can draw abritray things on the screen. When I was troubleshooting the 15c2:0038 device, I documented pretty thoroughly some of the steps I was taking to get to the bottom of it: http://codeka.com/forums/viewtopic.php?f=3&t=69&sid=24f2fa39b7b0acc203c05509057310c2#p443 In there, you will find the imon_poke code. You will want to change the code at the top that says the device ID from 0038 to 0044 - and then compile and run it. (The gcc arguments to compile it are in a comment at the top of the code) Once you run imon_poke - if you see it draw a line on your screen - you should be able to confirm that the device exists and it has the same driving protocol as the recent LCD screens. STEP 3: Get the LIRC driver to work with the device Use the CVS head code - as it has the latest changes for the lirc_imon device. At this point, you will need to add the device to the lirc_imon.c list of devices and recompile your lirc_imon.c and replace any lirc_imon.ko with the newly built one. To help you identify if the newly built one is working - you could throw a custom version number in your local build so you will be able to very easily tell when you check the output in dmesg that your version is loading and not some older version. Once you have the lirc_imon.ko in place you can kill any lirc processes, modprobe -r lirc_imon, and then modprobe lirc_imon debug=1 (the debug=1 is optional, but it will give you some more debug output) - and then see if /dev/lcd0 or /dev/lcd1 gets created... STEP 4: get your LCD to actually display something useful (outside the scope of LIRC) If they do, then your next step will be to get LCDd and lcdproc to work with them - but that's no longer a lirc issue. That first blog that I pointed you to has another page where he describes how to get LCDd and lcdproc to work with the imon LCD. If your device does, in fact, turn out to be a VFD - I personally haven't done much with the VFD's - but I think you should just be able to skip to step 3 and add it to the VFD list and then see if you can write ASCII out to the LCD device - as I think it just echoes ascii text (the LCD models draw bitmaps, but I think the VFDs let you pass in plain text) Ryan Thanks for your reply Ryan Yes, im relatively sure it's a VFD device. http://www.antec.com/ec/productDetails.php?ProdID=75223# Anyway the VFD of this device works well. I just disabled the usbhid driver for 15c2:0044 and added the device ID to the standalone iMON VFD drivers that can be found at http://venky.ws/projects/imon/#standalone The problem is that I can't get lirc0 and lirc1 to /dev. I compiled and installed it succesfully, modprobed lirc_imon also succesfully but for some reason the IR driver does not load. I suppose I just failed to edit the driver correctly. As I said, i'm no pro in this kind of stuff. -vika |
From: vika <vik...@ya...> - 2008-11-06 18:48:23
|
--- On Thu, 11/6/08, Jarod Wilson <ja...@wi...> wrote: > > > I'd wager a guess that the hid driver > captured your > > > device, and thus > > > lirc_imon isn't able to grab it. For example, > with my > > > new Antec toy, > > > prior to telling usbhid to ignore it: > > > > > > input: HID 15c2:0045 > > > as > > > > /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/input/input3 > > > input,hidraw0: USB HID v1.01 Mouse [HID > 15c2:0045] on > > > usb-0000:00:1d.1-1 > > > hiddev96hidraw1: USB HID v1.00 Device [HID > 15c2:0045] on > > > usb-0000:00:1d.1-1 > > > > I don't think so. I've quirked it so the > usbhid driver excludes the > > device with id 15c2:0044. So I get nothing when lsmod > | grep 0044. > > Anyways in the usb devices list it says Driver=(none), > it would say > > usbhid if that was the case. > > Okay, so perhaps then you have an old lirc_imon module > getting in the > way? My locally modified version definitely spews a ton of > stuff when > its loaded w/my 0045 quirked (doesn't actually work > yet, but working on > it...). Actually I compiled and installed this on fresh ubuntu 8.10 install so there shouldn't be anything getting in the way. Maybe running ubuntu 8.10 is the problem in the first place. Noticed some problems when running ./autogen. I don't know this has any affect at all because it still compiled and installed ok. libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./config.guess' libtoolize: copying file `./config.sub' libtoolize: copying file `./install-sh' libtoolize: copying file `./ltmain.sh' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. configure.ac: installing `./missing' daemons/Makefile.am: installing `./depcomp' Creating setup-driver.sh ... > > > > BTW, The patch was't actually for the > same version > > > of lirc_imon.c that is > > > > available at CVS... but did the job. > > > > > > Eh? I generated it off of lirc cvs right after > doing a cvs > > > up... Sure your local copy was up to date? > > > > I'm not sure about this but I think the patch is > trying to find a > > lirc_imon.c file dated on 15th-Oct as the one in cvs > is dated 16th. > > Date shouldn't matter here. I suspect the date > difference is simply from > me making the changes locally on the 15th, the committing > them on the > 16th. If the diff applies and things compile, its probably > all good. > Yeah, everything went ok. I just needed to point to the lirc_imon.c when asked. I think I used "p1" parameter when applying the patch so that makes it search the file from wrong place... |
From: Jarod W. <ja...@wi...> - 2008-11-06 19:24:28
|
On Thu, 2008-11-06 at 10:48 -0800, vika wrote: > --- On Thu, 11/6/08, Jarod Wilson <ja...@wi...> wrote: > > > > > I'd wager a guess that the hid driver > > captured your > > > > device, and thus > > > > lirc_imon isn't able to grab it. For example, > > with my > > > > new Antec toy, > > > > prior to telling usbhid to ignore it: > > > > > > > > input: HID 15c2:0045 > > > > as > > > > > > /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/input/input3 > > > > input,hidraw0: USB HID v1.01 Mouse [HID > > 15c2:0045] on > > > > usb-0000:00:1d.1-1 > > > > hiddev96hidraw1: USB HID v1.00 Device [HID > > 15c2:0045] on > > > > usb-0000:00:1d.1-1 > > > > > > I don't think so. I've quirked it so the > > usbhid driver excludes the > > > device with id 15c2:0044. So I get nothing when lsmod > > | grep 0044. > > > Anyways in the usb devices list it says Driver=(none), > > it would say > > > usbhid if that was the case. > > > > Okay, so perhaps then you have an old lirc_imon module > > getting in the way? My locally modified version definitely > > spews a ton of stuff when > > its loaded w/my 0045 quirked (doesn't actually work > > yet, but working on it...). > > Actually I compiled and installed this on fresh ubuntu 8.10 install so > there shouldn't be anything getting in the way. Maybe running ubuntu > 8.10 is the problem in the first place. Ubuntu carries lirc kernel patches, so I'm pretty sure there is an lirc_imon driver already on your system. > Noticed some problems when > running ./autogen. I don't know this has any affect at all because > it still compiled and installed ok. > > libtoolize: putting auxiliary files in `.'. > libtoolize: copying file `./config.guess' > libtoolize: copying file `./config.sub' > libtoolize: copying file `./install-sh' > libtoolize: copying file `./ltmain.sh' > libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and > libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. > libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. > configure.ac: installing `./missing' > daemons/Makefile.am: installing `./depcomp' > Creating setup-driver.sh ... No clue what that's about. > Yeah, everything went ok. I just needed to point to the lirc_imon.c > when asked. I think I used "p1" parameter when applying the patch > so that makes it search the file from wrong place... Oh yeah. I forget that cvs diff does relative paths, vs. git, which does full paths. -- Jarod Wilson ja...@wi... |
From: vika <vik...@ya...> - 2008-11-07 14:38:26
|
--- On Thu, 11/6/08, Jarod Wilson <ja...@wi...> wrote: > Ubuntu carries lirc kernel patches, so I'm pretty sure > there is an > lirc_imon driver already on your system. Yep, you were right. Removed lirc modules from ubuntu install and reinstalled lirc from 0044 patched source. So far both, VFD and IR receiver, are working. Thanks! How's it going with the 0045? -vika |
From: Kou <kk...@gm...> - 2008-11-07 14:47:30
|
you can always check with modinfo which version is loaded, modinfo shows a path to module file, which is/will be loaded, usually cvs version installs to /lib/modules/****/misc/ dir. I still need to check the patch with my 0036, but my 2 weeks old son is not giving me a chance to do so ;) Kou On Fri, Nov 7, 2008 at 3:38 PM, vika <vik...@ya...> wrote: > --- On Thu, 11/6/08, Jarod Wilson <ja...@wi...> wrote: >> Ubuntu carries lirc kernel patches, so I'm pretty sure >> there is an >> lirc_imon driver already on your system. > > Yep, you were right. Removed lirc modules from ubuntu install and reinstalled lirc from 0044 patched source. So far both, VFD and IR receiver, are working. Thanks! > > How's it going with the 0045? > > -vika > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > |
From: Jarod W. <ja...@wi...> - 2008-11-07 15:10:30
|
On Fri, 2008-11-07 at 06:38 -0800, vika wrote: > --- On Thu, 11/6/08, Jarod Wilson <ja...@wi...> wrote: > > Ubuntu carries lirc kernel patches, so I'm pretty sure > > there is an > > lirc_imon driver already on your system. > > Yep, you were right. Removed lirc modules from ubuntu install and > reinstalled lirc from 0044 patched source. So far both, VFD and > IR receiver, are working. Thanks! Excellent! We'll get something committed to lirc soon... > How's it going with the 0045? Ran out of time to play with it yesterday, haven't had a chance to poke yet today. Last I prodded, irw wasn't picking up any key presses yet, and I hadn't yet patched up lcdproc for imonlcd support. Hoping to play with it some today, if not, then this weekend. -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2008-11-07 16:20:59
|
On Fri, 2008-11-07 at 10:10 -0500, Jarod Wilson wrote: > > How's it going with the 0045? > > Ran out of time to play with it yesterday, haven't had a chance to > poke > yet today. Last I prodded, irw wasn't picking up any key presses yet, > and I hadn't yet patched up lcdproc for imonlcd support. Hoping to > play with it some today, if not, then this weekend. Got the display working now, lcdproc is currently doing its thing. IR isn't working just yet though, still poking around to try to figure out why. These are definitely funky devices. Registers as two lirc devices, /dev/lirc0 and /dev/lirc1, and both lirc devices wind up with corresponding /dev/lcdX devices (lcd0 is the one I'm working with, no clue what would happen if I tried poking lcd1). -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2008-11-07 17:52:29
|
On Fri, 2008-11-07 at 11:20 -0500, Jarod Wilson wrote: > On Fri, 2008-11-07 at 10:10 -0500, Jarod Wilson wrote: > > > How's it going with the 0045? > > > > Ran out of time to play with it yesterday, haven't had a chance to > > poke > > yet today. Last I prodded, irw wasn't picking up any key presses yet, > > and I hadn't yet patched up lcdproc for imonlcd support. Hoping to > > play with it some today, if not, then this weekend. > > Got the display working now, lcdproc is currently doing its thing. IR > isn't working just yet though, still poking around to try to figure out > why. > > These are definitely funky devices. Registers as two lirc > devices, /dev/lirc0 and /dev/lirc1, ...which requires some effort to make everything work. Ron Frazier's got details here: http://mythtvblog.blogspot.com/2008/04/getting-imon-0038-lcd-working-with-lirc.html (see step 5) With that, I'm now getting IR signals for at least a good portion of the buttons on the remote that came w/the thing, using the imon-pad remote def file in cvs right now. May need to move to a full 8-byte buffer config to get everything working. (None of the front-panel buttons are coming through at the moment and a few keys do nothing). > and both lirc devices wind up with > corresponding /dev/lcdX devices (lcd0 is the one I'm working with, no > clue what would happen if I tried poking lcd1). According to Ron, lcd1 simply points to the same usb endpoint, so lcd0 and lcd1 should behave the same. Worth eliminating the extraneous one at some point, but eh. Lower priority than some other things... So yeah, basic IR and LCD output are now working. -- Jarod Wilson ja...@wi... |
From: vika <vik...@ya...> - 2008-11-07 18:23:05
|
--- On Fri, 11/7/08, Jarod Wilson <ja...@wi...> wrote: > ...which requires some effort to make everything work. Ron > Frazier's got > details here: > > http://mythtvblog.blogspot.com/2008/04/getting-imon-0038-lcd-working-with-lirc.html > > (see step 5) > > With that, I'm now getting IR signals for at least a > good portion of the > buttons on the remote that came w/the thing, using the > imon-pad remote > def file in cvs right now. May need to move to a full > 8-byte buffer > config to get everything working. (None of the front-panel > buttons are > coming through at the moment and a few keys do nothing). I used also Rons instructions to get all buttons on the remote work. Suppose you have also the pad remote? Have you noticed that when you push for example the play button on it gets one command and when you release it gets another command. when pushed down (fourth from right is 1): code: 0x2a8115b7 when released (fourth from right is 5): code: 0x2a8155b7 This causes some problems with eg. the "right menu" button (the one without text label and is on the right side of the pad). Somehow lirc thinks that "Backspace" is pushed when this button is released. This happens with lirc.conf made with irrecord. -vika |
From: Jarod W. <ja...@wi...> - 2008-11-07 21:48:38
|
On Fri, 2008-11-07 at 10:23 -0800, vika wrote: > --- On Fri, 11/7/08, Jarod Wilson <ja...@wi...> wrote: > > ...which requires some effort to make everything work. Ron > > Frazier's got > > details here: > > > > http://mythtvblog.blogspot.com/2008/04/getting-imon-0038-lcd-working-with-lirc.html > > > > (see step 5) > > > > With that, I'm now getting IR signals for at least a > > good portion of the > > buttons on the remote that came w/the thing, using the > > imon-pad remote > > def file in cvs right now. May need to move to a full > > 8-byte buffer > > config to get everything working. (None of the front-panel > > buttons are > > coming through at the moment and a few keys do nothing). > > I used also Rons instructions to get all buttons on the remote work. Suppose > you have also the pad remote? Have you noticed that when you push for example > the play button on it gets one command and when you release it gets another > command. > > when pushed down (fourth from right is 1): > code: 0x2a8115b7 > > when released (fourth from right is 5): > code: 0x2a8155b7 In looking at the buffer contents as the come off the thing, for a given keycode 'foo', you get that keycode repeating while the key is held down, and upon finally releasing the key, you get a 'foo | 0x00004000' "key" in the buffer. Looks like its the onboard decoding's way of signaling that the key is no longer being pressed. Similar, I'm seeing a key release code for several 0x02xxxxxx buttons of 0x02000000, and an 0x01000000 upon releasing either of the mouse click buttons. Seems there's a lot more useful information automagically coming off of the receiver that we could do something with... > This causes some problems with eg. the "right menu" button (the one without > text label and is on the right side of the pad). Somehow lirc thinks that > "Backspace" is pushed when this button is released. Haven't run into that, but I have had things appear to get wedged somehow, such that irw kept seeing VolDown events from the panel, even when none were coming in... Not sure yet how to remedy that. > This happens with lirc.conf made with irrecord. I generated a clean lircd.conf by hand, using debug spew from the driver itself, which can be made to output the decoded values into dmesg. http://wilsonet.com/jarod/junk/lircd-antec-veris-premiere.conf For some reason, the TV button on my panel does *nothing*, but with this config file, everything save the TV button and volume down on the panel knob work perfectly fine now (using a 64-bit buffer though). -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2008-11-08 06:10:21
|
On Fri, 2008-11-07 at 16:48 -0500, Jarod Wilson wrote: > On Fri, 2008-11-07 at 10:23 -0800, vika wrote: > > --- On Fri, 11/7/08, Jarod Wilson <ja...@wi...> wrote: > > > ...which requires some effort to make everything work. Ron > > > Frazier's got > > > details here: > > > > > > http://mythtvblog.blogspot.com/2008/04/getting-imon-0038-lcd-working-with-lirc.html > > > > > > (see step 5) > > > > > > With that, I'm now getting IR signals for at least a > > > good portion of the > > > buttons on the remote that came w/the thing, using the > > > imon-pad remote > > > def file in cvs right now. May need to move to a full > > > 8-byte buffer > > > config to get everything working. (None of the front-panel > > > buttons are > > > coming through at the moment and a few keys do nothing). > > > > I used also Rons instructions to get all buttons on the remote work. Suppose > > you have also the pad remote? Have you noticed that when you push for example > > the play button on it gets one command and when you release it gets another > > command. > > > > when pushed down (fourth from right is 1): > > code: 0x2a8115b7 > > > > when released (fourth from right is 5): > > code: 0x2a8155b7 > > In looking at the buffer contents as the come off the thing, for a given > keycode 'foo', you get that keycode repeating while the key is held > down, and upon finally releasing the key, you get a 'foo | 0x00004000' > "key" in the buffer. Looks like its the onboard decoding's way of > signaling that the key is no longer being pressed. > > Similar, I'm seeing a key release code for several 0x02xxxxxx buttons of > 0x02000000, and an 0x01000000 upon releasing either of the mouse click > buttons. Seems there's a lot more useful information automagically > coming off of the receiver that we could do something with... > > > This causes some problems with eg. the "right menu" button (the one without > > text label and is on the right side of the pad). Somehow lirc thinks that > > "Backspace" is pushed when this button is released. > > Haven't run into that, but I have had things appear to get wedged > somehow, such that irw kept seeing VolDown events from the panel, even > when none were coming in... Not sure yet how to remedy that. > > > This happens with lirc.conf made with irrecord. > > I generated a clean lircd.conf by hand, using debug spew from the driver > itself, which can be made to output the decoded values into dmesg. > > http://wilsonet.com/jarod/junk/lircd-antec-veris-premiere.conf > > For some reason, the TV button on my panel does *nothing*, but with this > config file, everything save the TV button and volume down on the panel > knob work perfectly fine now (using a 64-bit buffer though). The above link has an updated config file there now which is working flawlessly with every button on the display and on the remote, save the TV button on the panel, which appears to be busted. I've gone ahead and committed a fairly hefty lirc_imon patch that adds support for the 0045, as well as the 0044 and 0041 devices I know are out there, as well as potential/theoretical 0042 and 0043 devices (which may be the other two Antec IR-only devices I saw on newegg.com). Also flipped the 0038 along with the 0045 to use an 8-byte buffer so that all the keys on both the remote and panel will work. Might break a few people's existing 0038 setups... But I think its worth the change -- the 0045 really is working quite beautifully for me now. -- Jarod Wilson ja...@wi... |
From: vika <vik...@ya...> - 2008-11-09 19:55:01
|
--- On Sat, 11/8/08, Jarod Wilson <ja...@wi...> wrote: > The above link has an updated config file there now which > is working > flawlessly with every button on the display and on the > remote, save the > TV button on the panel, which appears to be busted. > I've gone ahead and > committed a fairly hefty lirc_imon patch that adds support > for the 0045, > as well as the 0044 and 0041 devices I know are out there, > as well as > potential/theoretical 0042 and 0043 devices (which may be > the other two > Antec IR-only devices I saw on newegg.com). Also flipped > the 0038 along > with the 0045 to use an 8-byte buffer so that all the keys > on both the > remote and panel will work. Might break a few people's > existing 0038 > setups... But I think its worth the change -- the 0045 > really is working > quite beautifully for me now. > I think also the device 0044 should be added to the large buffed device list. It helps to prevent atleast some of the "false commands" I get when releasing a button. BTW, is there any disadvantages when using larger buffer if it's not necessary? I checked the volume knob on the device and I got nothing out from it. I compiled lirc with --debug-enabled and got the buttons on the remote to show up in dmesg but the volume knob didn't give anything. This is not important to me but better make it perfect.. -vika |
From: <li...@ba...> - 2008-11-09 20:14:34
|
Hi! vika "vik...@ya..." wrote: [...] > I think also the device 0044 should be added to the large buffed device > list. It helps to prevent atleast some of the "false commands" I get when > releasing a button. BTW, is there any disadvantages when using larger buffer > if it's not necessary? No, I think new devices should always be added to the large buffer device list. The problem with already supported devices is that users would have to change their existing config files if we changed all devices to use the large buffers. Maybe defining a "small buffer devices list" would make sense so that the large buffer is used automatically for all new devices. Christoph |
From: Jarod W. <ja...@wi...> - 2008-11-10 06:17:36
|
On Sun, 2008-11-09 at 21:14 +0100, Christoph Bartelmus wrote: > Hi! > > vika "vik...@ya..." wrote: > [...] > > I think also the device 0044 should be added to the large buffed device > > list. It helps to prevent atleast some of the "false commands" I get when > > releasing a button. BTW, is there any disadvantages when using larger buffer > > if it's not necessary? > > No, I think new devices should always be added to the large buffer device > list. The problem with already supported devices is that users would have > to change their existing config files if we changed all devices to use the > large buffers. > Maybe defining a "small buffer devices list" would make sense so that the > large buffer is used automatically for all new devices. I like it, I'll go ahead and do that. --jarod |
From: vika <vik...@ya...> - 2008-11-10 14:51:32
|
--- On Mon, 11/10/08, Jarod Wilson <ja...@wi...> wrote: > > vika "vik...@ya..." wrote: > > [...] > > > I think also the device 0044 should be added to > the large buffed device > > > list. It helps to prevent atleast some of the > "false commands" I get when > > > releasing a button. BTW, is there any > disadvantages when using larger buffer > > > if it's not necessary? > > > > No, I think new devices should always be added to the > large buffer device > > list. The problem with already supported devices is > that users would have > > to change their existing config files if we changed > all devices to use the > > large buffers. > > Maybe defining a "small buffer devices list" > would make sense so that the > > large buffer is used automatically for all new > devices. > > I like it, I'll go ahead and do that. > > --jarod Great. So... do you have any tips to get the volume knob on the panel work? I'm getting nothing from it thru lirc0 or lirc1. -vika |
From: Jarod W. <ja...@wi...> - 2008-11-10 17:16:36
|
On Mon, 2008-11-10 at 06:51 -0800, vika wrote: > --- On Mon, 11/10/08, Jarod Wilson <ja...@wi...> wrote: > > > vika "vik...@ya..." wrote: > > > [...] > > > > I think also the device 0044 should be added to > > the large buffed device > > > > list. It helps to prevent atleast some of the > > "false commands" I get when > > > > releasing a button. BTW, is there any > > disadvantages when using larger buffer > > > > if it's not necessary? > > > > > > No, I think new devices should always be added to the > > large buffer device > > > list. The problem with already supported devices is > > that users would have > > > to change their existing config files if we changed > > all devices to use the > > > large buffers. > > > Maybe defining a "small buffer devices list" > > would make sense so that the > > > large buffer is used automatically for all new > > devices. > > > > I like it, I'll go ahead and do that. > > > > --jarod > > > Great. > > So... do you have any tips to get the volume knob on the panel work? > I'm getting nothing from it thru lirc0 or lirc1. Can't remember... Did you already enable debugging in your build, so that the driver spits out the decoded signals coming off the device? Should be as simple as doing that, and adding appropriate lines to your lircd.conf based on that spew. -- Jarod Wilson ja...@wi... |
From: vika <vik...@ya...> - 2008-11-10 18:07:44
|
--- On Mon, 11/10/08, Jarod Wilson <ja...@wi...> wrote: > From: Jarod Wilson <ja...@wi...> > Subject: Re: iMon 15c2:0045 progress > To: lir...@li... > Date: Monday, November 10, 2008, 7:16 PM > On Mon, 2008-11-10 at 06:51 -0800, vika wrote: > > --- On Mon, 11/10/08, Jarod Wilson > <ja...@wi...> wrote: > > > > vika "vik...@ya..." wrote: > > > > [...] > > > > > I think also the device 0044 should be > added to > > > the large buffed device > > > > > list. It helps to prevent atleast some > of the > > > "false commands" I get when > > > > > releasing a button. BTW, is there any > > > disadvantages when using larger buffer > > > > > if it's not necessary? > > > > > > > > No, I think new devices should always be > added to the > > > large buffer device > > > > list. The problem with already supported > devices is > > > that users would have > > > > to change their existing config files if we > changed > > > all devices to use the > > > > large buffers. > > > > Maybe defining a "small buffer devices > list" > > > would make sense so that the > > > > large buffer is used automatically for all > new > > > devices. > > > > > > I like it, I'll go ahead and do that. > > > > > > --jarod > > > > > > Great. > > > > So... do you have any tips to get the volume knob on > the panel work? > > I'm getting nothing from it thru lirc0 or lirc1. > > > Can't remember... Did you already enable debugging in > your build, so > that the driver spits out the decoded signals coming off > the device? > Should be as simple as doing that, and adding appropriate > lines to your > lircd.conf based on that spew. Yes, I succesfully enabled debug and got lirc to spit the decoded signals to dmesg when pushin buttons on remote, no signals from the knob though. -vika |
From: Jarod W. <ja...@wi...> - 2008-11-10 18:22:42
|
On Mon, 2008-11-10 at 10:07 -0800, vika wrote: > --- On Mon, 11/10/08, Jarod Wilson <ja...@wi...> wrote: > > From: Jarod Wilson <ja...@wi...> > > Subject: Re: iMon 15c2:0045 progress > > To: lir...@li... > > Date: Monday, November 10, 2008, 7:16 PM > > On Mon, 2008-11-10 at 06:51 -0800, vika wrote: > > > --- On Mon, 11/10/08, Jarod Wilson > > <ja...@wi...> wrote: > > > > > vika "vik...@ya..." wrote: > > > > > [...] > > > > > > I think also the device 0044 should be > > added to > > > > the large buffed device > > > > > > list. It helps to prevent atleast some > > of the > > > > "false commands" I get when > > > > > > releasing a button. BTW, is there any > > > > disadvantages when using larger buffer > > > > > > if it's not necessary? > > > > > > > > > > No, I think new devices should always be > > added to the > > > > large buffer device > > > > > list. The problem with already supported > > devices is > > > > that users would have > > > > > to change their existing config files if we > > changed > > > > all devices to use the > > > > > large buffers. > > > > > Maybe defining a "small buffer devices > > list" > > > > would make sense so that the > > > > > large buffer is used automatically for all > > new > > > > devices. > > > > > > > > I like it, I'll go ahead and do that. > > > > > > > > --jarod > > > > > > > > > Great. > > > > > > So... do you have any tips to get the volume knob on > > the panel work? > > > I'm getting nothing from it thru lirc0 or lirc1. > > > > > > Can't remember... Did you already enable debugging in > > your build, so > > that the driver spits out the decoded signals coming off > > the device? > > Should be as simple as doing that, and adding appropriate > > lines to your > > lircd.conf based on that spew. > > Yes, I succesfully enabled debug and got lirc to spit the decoded > signals to dmesg when pushin buttons on remote, no signals from the > knob though. Crap, now I recall you saying that. If you're not getting anything there, I don't have any suggestions outside of seeing what it does uder that other OS. :( I actually kinda want to do the same w/mine for the DVD button on the panel, which doesn't seem to send anything either... -- Jarod Wilson ja...@wi... |
From: vika <vik...@ya...> - 2008-11-10 18:34:37
|
--- On Mon, 11/10/08, Jarod Wilson <ja...@wi...> wrote: > From: Jarod Wilson <ja...@wi...> > Subject: Re: iMon 15c2:0045 progress > To: lir...@li... > Date: Monday, November 10, 2008, 8:22 PM > On Mon, 2008-11-10 at 10:07 -0800, vika wrote: > > --- On Mon, 11/10/08, Jarod Wilson > <ja...@wi...> wrote: > > > From: Jarod Wilson <ja...@wi...> > > > Subject: Re: iMon 15c2:0045 progress > > > To: lir...@li... > > > Date: Monday, November 10, 2008, 7:16 PM > > > On Mon, 2008-11-10 at 06:51 -0800, vika wrote: > > > > --- On Mon, 11/10/08, Jarod Wilson > > > <ja...@wi...> wrote: > > > > > > vika > "vik...@ya..." wrote: > > > > > > [...] > > > > > > > I think also the device 0044 > should be > > > added to > > > > > the large buffed device > > > > > > > list. It helps to prevent > atleast some > > > of the > > > > > "false commands" I get when > > > > > > > releasing a button. BTW, is > there any > > > > > disadvantages when using larger buffer > > > > > > > if it's not necessary? > > > > > > > > > > > > No, I think new devices should > always be > > > added to the > > > > > large buffer device > > > > > > list. The problem with already > supported > > > devices is > > > > > that users would have > > > > > > to change their existing config > files if we > > > changed > > > > > all devices to use the > > > > > > large buffers. > > > > > > Maybe defining a "small > buffer devices > > > list" > > > > > would make sense so that the > > > > > > large buffer is used automatically > for all > > > new > > > > > devices. > > > > > > > > > > I like it, I'll go ahead and do > that. > > > > > > > > > > --jarod > > > > > > > > > > > > Great. > > > > > > > > So... do you have any tips to get the volume > knob on > > > the panel work? > > > > I'm getting nothing from it thru lirc0 > or lirc1. > > > > > > > > > Can't remember... Did you already enable > debugging in > > > your build, so > > > that the driver spits out the decoded signals > coming off > > > the device? > > > Should be as simple as doing that, and adding > appropriate > > > lines to your > > > lircd.conf based on that spew. > > > > Yes, I succesfully enabled debug and got lirc to spit > the decoded > > signals to dmesg when pushin buttons on remote, no > signals from the > > knob though. > > Crap, now I recall you saying that. If you're not > getting anything > there, I don't have any suggestions outside of seeing > what it does uder > that other OS. :( > > I actually kinda want to do the same w/mine for the DVD > button on the > panel, which doesn't seem to send anything either... hmm.. I have vista installed, maybe i could do some study with it? I've never probed usb traffic so could you point me to right direction. Thanks. -vika |
From: Jarod W. <ja...@wi...> - 2008-11-10 18:48:54
|
On Mon, 2008-11-10 at 10:34 -0800, vika wrote: > > I actually kinda want to do the same w/mine for the DVD > > button on the > > panel, which doesn't seem to send anything either... > > hmm.. I have vista installed, maybe i could do some study with it? > I've never probed usb traffic so could you point me to right > direction. Thanks. First up, I'd just install the Windows drivers, and see if the volume knob actually does anything, no sniffing needed. But what I've used to sniff usb traffic under Windows is SniffUSB. http://www.pcausa.com/Utilities/UsbSnoop/default.htm -- Jarod Wilson ja...@wi... |
From: vika <vik...@ya...> - 2008-11-10 23:12:54
|
--- On Mon, 11/10/08, Jarod Wilson <ja...@wi...> wrote: > > hmm.. I have vista installed, maybe i could do some > study with it? > > I've never probed usb traffic so could you point > me to right > > direction. Thanks. > > First up, I'd just install the Windows drivers, and see > if the volume > knob actually does anything, no sniffing needed. But what > I've used to > sniff usb traffic under Windows is SniffUSB. > > http://www.pcausa.com/Utilities/UsbSnoop/default.htm Got the usb sniffer up and running and after a while playing with the imon windows drivers/software I found out something interesting. It seems that the knob needs some kind of command or impulse or something to start work. First of all, the sniffer log collects loads and loads of stuff because of the imon software, more accurately, the part of the software which is named FrontView. FrontView is like LCDproc in linux, it feeds stuff to the VFD/LCD. So I turned off this FrontView to stop all extra traffic in the usb. After this, I was able to parse the decoded signals from the log. The thing is that I can get only remote control signals when the FrontView is not running. The knob needs this FrontView app running to get any signal from it. I believe there is some register or something that enabled when FrontView is running. I was a bit amazed by this because it means that the knob doesn't work with any 3rd party software. -vika |
From: vika <vik...@ya...> - 2008-11-17 15:03:17
|
--- On Mon, 11/10/08, Jarod Wilson <ja...@wi...> wrote:> > First up, I'd just install the Windows drivers, and see > if the volume > knob actually does anything, no sniffing needed. But what > I've used to > sniff usb traffic under Windows is SniffUSB. > > http://www.pcausa.com/Utilities/UsbSnoop/default.htm Jarod, Any progress with the unfunctional button on your panel? I updated the driver on vista and sniffed the signals from the knob successfully, so in windows the device is working as it should. Decoded signals from 0044 were the same you got from device 0045. -vika |
From: Jarod W. <ja...@wi...> - 2008-11-17 19:10:28
|
On Mon, 2008-11-17 at 07:03 -0800, vika wrote: > --- On Mon, 11/10/08, Jarod Wilson <ja...@wi...> wrote:> > > First up, I'd just install the Windows drivers, and see > > if the volume > > knob actually does anything, no sniffing needed. But what > > I've used to > > sniff usb traffic under Windows is SniffUSB. > > > > http://www.pcausa.com/Utilities/UsbSnoop/default.htm > > Jarod, > > Any progress with the unfunctional button on your panel? I updated > the driver on vista and sniffed the signals from the knob successfully, > so in windows the device is working as it should. Decoded signals from > 0044 were the same you got from device 0045. Nope, haven't got around to prodding it any further, severely lacking time to work on it. I did look at mouse/keyboard mode toggle stuff a bit over the weekend though... --jarod |
From: Jarod W. <ja...@wi...> - 2008-11-07 16:23:40
|
On Fri, 2008-11-07 at 15:47 +0100, Kou wrote: > you can always check with modinfo which version is loaded, modinfo > shows a path to module file, which is/will be loaded, usually cvs > version installs to /lib/modules/****/misc/ dir. > > I still need to check the patch with my 0036, Fingers crossed. Pretty sure it should Just Work(tm) w/that patch, based on the fact it should follow the exact same code paths as the 0044. > but my 2 weeks old son > is not giving me a chance to do so ;) I know how that goes. We've got a 6 year old and a 3 year old of our own, and just started doing foster care about 3 weeks ago, so we've got a brand new 2mo old kid in the house too. My free time has dropped precipitously... :) -- Jarod Wilson ja...@wi... |
From: Kou <kk...@gm...> - 2008-11-08 16:20:40
|
Hi, so I compiled the latest CVS source and 0036 is correctly detected and /dev/lcd0 and /dev/lcd1 are created. However the behaviour is the same as with standalone imon_vfd module - text is garbled with non-alphanumeric characters. I made a short video of what it looks like - first few seconds are with LCDd running only, then ldcproc was fired up .... http://www.youtube.com/watch?v=kSkMSpZB91A Probably some formatting issue ? Kou On Fri, Nov 7, 2008 at 5:23 PM, Jarod Wilson <ja...@wi...> wrote: > On Fri, 2008-11-07 at 15:47 +0100, Kou wrote: >> you can always check with modinfo which version is loaded, modinfo >> shows a path to module file, which is/will be loaded, usually cvs >> version installs to /lib/modules/****/misc/ dir. >> >> I still need to check the patch with my 0036, > > Fingers crossed. Pretty sure it should Just Work(tm) w/that patch, based > on the fact it should follow the exact same code paths as the 0044. > >> but my 2 weeks old son >> is not giving me a chance to do so ;) > > I know how that goes. We've got a 6 year old and a 3 year old of our > own, and just started doing foster care about 3 weeks ago, so we've got > a brand new 2mo old kid in the house too. My free time has dropped > precipitously... :) > > > -- > Jarod Wilson > ja...@wi... > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > |