From: Jarod W. <ja...@wi...> - 2010-03-24 21:44:15
|
On Tue, Mar 23, 2010 at 4:07 PM, Anders Eriksson <aer...@fa...> wrote: > >>Okay, I *think* this patch would do the trick. I've yet to actually >>test it out on my own hardware though... >> >>http://wilsonet.com/jarod/junk/imon-0xff4xx-keys.patch > > Tested it and it mostly works. Some keys give the wrong KEY_??? though. Nrgh. My dislike of SoundGraph increases... > Here's the ones: > > MENU -> KEY_DVD > PREV -> KEY_NUMERIC_POUND > STAR -> KEY_DELETE > GREEN -> KEY_TUNER > BLUE -> KEY_STAR > > These keys are now dead: > POUND > RED > YELLOW > > > Looking at the patch, and comparing the new one with mine, I see that my codes for e.g. RED differs from yours: > Mine: 0x800FF466 > Yours 0x800ff45b > > So there are some diffs in the lower bits as well :-( > > The same goes for PREV (mine is 0x800FF41C, not ....41B) > > However looking at MENU, it's the same code as you have mapped to DVD (...ff424). Updated patch here, also documents several places where your codes match a code for something else on another receiver/remote combo: http://wilsonet.com/jarod/junk/imon-0xff4xx-keys-v2.patch Starting to think a unified key table might be a pipe dream. Need to get on the support for remapping keys from userspace. Wonder how the imon windows driver handles this... -- Jarod Wilson ja...@wi... |
From: Dale P. <DEP...@ed...> - 2010-03-24 21:59:29
|
On 03/24/10 17:44, Jarod Wilson wrote: > Starting to think a unified key table might be a pipe dream. Need to > get on the support for remapping keys from userspace. Wonder how the > imon windows driver handles this... > I had to use irrecord to get my imon VFD to work, and at some point I think I'd experimented with every keyset they supplied. Would it be of any help if I gave you my keyset? (imon vfd + mce rd6 remote) Maybe with more of a collection some sort of pattern will emerge? Dale |
From: Jarod W. <ja...@wi...> - 2010-03-24 22:14:06
|
On Wed, Mar 24, 2010 at 5:59 PM, Dale Pontius <DEP...@ed...> wrote: > On 03/24/10 17:44, Jarod Wilson wrote: >> Starting to think a unified key table might be a pipe dream. Need to >> get on the support for remapping keys from userspace. Wonder how the >> imon windows driver handles this... >> > I had to use irrecord to get my imon VFD to work, and at some point I > think I'd experimented with every keyset they supplied. Would it be of > any help if I gave you my keyset? (imon vfd + mce rd6 remote) Maybe > with more of a collection some sort of pattern will emerge? Couldn't hurt to send it along, but the pattern seems to me to be "SoundGraph is a bunch of muppets". ;) (Though its *possible* its actually the remotes at fault -- i.e., one vendor using an rc6 code for something different than the next). -- Jarod Wilson ja...@wi... |
From: Dale P. <DEP...@ed...> - 2010-03-25 00:07:26
|
On 03/22/10 12:15, Marco Salvagno wrote: > BTW I'm still experiencing that problem with LCDd blasting the iMon > and generating packet write errors. Is that an issue that will have to > find a fix within LCDd ? Let me just check if I'm having the same problem. Every now an then, my VFD starts spouting gibberish - not even ASCII characters. Once it has started, it doesn't stop until I physically remove power - a reboot or even a regular powerdown doesn't do it. (I suspect it's really turning the 5VSB supply off.) I haven't tried just stopping LCDd, or even stopping the other drivers and unloading lirc_imon. I would have figured a regular shutdown should suffice for that. Is this the same problem as you have, or something else? Dale Pontius |
From: Marco S. <mar...@gm...> - 2010-03-25 01:24:43
|
On Thu, Mar 25, 2010 at 01:07, Dale Pontius <DEP...@ed...> wrote: > > Is this the same problem as you have, or something else? > > You might want to check your syslog, if you haven't already. I have always been finding write error messages in it since day 0. With the older driver, however display went blank until LCDd was restarted, the one I'm using now seems to be more tolerant, so no more manual restarts, although for some reason one of those write errors seems to be turning backlight on when it should stay off. If you're using XBMC, you might try editing the screensaver strings (IIRC it defaults to a big font clock). I tried that too to no avail, but many people submitted positive reports. For the record I'm using a 0038 LCD device. Hope this helps. -- Marco |
From: Jarod W. <ja...@wi...> - 2010-03-25 03:02:05
|
On Wed, Mar 24, 2010 at 9:24 PM, Marco Salvagno <mar...@gm...> wrote: > On Thu, Mar 25, 2010 at 01:07, Dale Pontius <DEP...@ed...> wrote: >> >> Is this the same problem as you have, or something else? >> > > You might want to check your syslog, if you haven't already. I have always > been finding write error messages in it since day 0. > > With the older driver, however display went blank until LCDd was restarted, > the one I'm using now seems to be more tolerant, so no more manual restarts, > although for some reason one of those write errors seems to be turning > backlight on when it should stay off. > > If you're using XBMC, you might try editing the screensaver strings (IIRC it > defaults to a big font clock). I tried that too to no avail, but many people > submitted positive reports. > > For the record I'm using a 0038 LCD device. Hope this helps. I believe this is a different problem. The gibberish-on-the-screen thing where the display can't be recovered until power is entirely removed seems to be an 0xffdc-device-specific problem. I'm hoping I can reproduce this one on the 0xffdc display someone is kindly sending my way. -- Jarod Wilson ja...@wi... |
From: Dale E. P. <DEP...@ed...> - 2010-03-25 17:45:59
|
On 03/24/10 23:01, Jarod Wilson wrote: > On Wed, Mar 24, 2010 at 9:24 PM, Marco Salvagno > <mar...@gm...> wrote: > >> On Thu, Mar 25, 2010 at 01:07, Dale Pontius <DEP...@ed...> wrote: >> >>> Is this the same problem as you have, or something else? >>> >>> >> You might want to check your syslog, if you haven't already. I have always >> been finding write error messages in it since day 0. >> >> With the older driver, however display went blank until LCDd was restarted, >> the one I'm using now seems to be more tolerant, so no more manual restarts, >> although for some reason one of those write errors seems to be turning >> backlight on when it should stay off. >> >> If you're using XBMC, you might try editing the screensaver strings (IIRC it >> defaults to a big font clock). I tried that too to no avail, but many people >> submitted positive reports. >> >> For the record I'm using a 0038 LCD device. Hope this helps. >> > I believe this is a different problem. The gibberish-on-the-screen > thing where the display can't be recovered until power is entirely > removed seems to be an 0xffdc-device-specific problem. I'm hoping I > can reproduce this one on the 0xffdc display someone is kindly sending > my way. > > I suspect that there is at least a hardware sensitivity to this, though there may be more. We're just coming out of winter - ESD season. On my system with the imon VFG (Antec Veris - Christmas 2008 vintage) I found that if I touched the case and felt a spark, it *might* make the system reboot. I'm a little surprised about this, because it would indicate to me a weak ground somewhere. I would have expected the case to be a good, firm ground, and a fairly safe way to discharge myself. For a weaker static event, one that didn't reboot the system, it would frequently make the imon VFD go into gibberish mode. If I could feel any discharge at all, and if it was weak enough to not reboot the system, gibberish mode happened. Not that I was doing this for fun and games - I generally tried other discharge means - but sometimes there was still a little zap left. That's still not the whole story, because I've been using suspend-to-ram, and haven't even touched the system itself in some time - I power it back up with the remote. But it's still in gibberish mode, even without me drawing a spark. That's not to say that there may not be some internal mechanism for throwing noise in there, perhaps on the ground wire. I haven't looked at the hardware lately - it might be interesting to see if adding an extra wire to chassis ground would help. In any event, does this bugger have a true reset operation? Are the drivers counting on it being reset by power on, or is there another reset operation they could invoke, in addition? Perhaps blast it with near-reset ops, kind of like TV-be-gone. Dale Pontius |
From: Jarod W. <ja...@wi...> - 2010-04-01 20:26:24
|
On Thu, Mar 25, 2010 at 1:43 PM, Dale E. Pontius <DEP...@ed...> wrote: > On 03/24/10 23:01, Jarod Wilson wrote: >> On Wed, Mar 24, 2010 at 9:24 PM, Marco Salvagno >> <mar...@gm...> wrote: >> >>> On Thu, Mar 25, 2010 at 01:07, Dale Pontius <DEP...@ed...> wrote: >>> >>>> Is this the same problem as you have, or something else? >>>> >>>> >>> You might want to check your syslog, if you haven't already. I have always >>> been finding write error messages in it since day 0. >>> >>> With the older driver, however display went blank until LCDd was restarted, >>> the one I'm using now seems to be more tolerant, so no more manual restarts, >>> although for some reason one of those write errors seems to be turning >>> backlight on when it should stay off. >>> >>> If you're using XBMC, you might try editing the screensaver strings (IIRC it >>> defaults to a big font clock). I tried that too to no avail, but many people >>> submitted positive reports. >>> >>> For the record I'm using a 0038 LCD device. Hope this helps. >>> >> I believe this is a different problem. The gibberish-on-the-screen >> thing where the display can't be recovered until power is entirely >> removed seems to be an 0xffdc-device-specific problem. I'm hoping I >> can reproduce this one on the 0xffdc display someone is kindly sending >> my way. So I've got an 0xffdc vfd in hand now. But I can't reproduce the display lockups on it. Even when having lcdproc blast data to it simultaneous with me using the directional pad, which sends a constant stream of varying IR signals. However, I'm using the imon driver, not lirc_imon, and I *did* put in some code to imon but not lirc_imon that I thought might help with the gibberish issue, so I should probably retest with lirc_imon. I've also got a mandatory delay-on-exiting-send_packet patch based on something someone in ubuntu's bug tracker (sigh, its been there a while, nobody ever bothered to send it upstream), which supposedly helps with gibberish for someone with one of the newer displays. The other interesting bit I've stumbled on to... The ffdc devices do NOT support switching ir protocols. Its hard-coded in their firmware whether they support the imon ir protocol or mce ir protocol. I *think* I've figured out where in the usb device config struct ffdc device specifics, like 'has lcd', 'has vfd', 'ir protocol imon', etc are stored, but I need to code up some debug patches and collect data for more devices to get a better idea. > I suspect that there is at least a hardware sensitivity to this, though > there may be more. We're just coming out of winter - ESD season. On my > system with the imon VFG (Antec Veris - Christmas 2008 vintage) I found > that if I touched the case and felt a spark, it *might* make the system > reboot. I'm a little surprised about this, because it would indicate to > me a weak ground somewhere. I would have expected the case to be a > good, firm ground, and a fairly safe way to discharge myself. > > For a weaker static event, one that didn't reboot the system, it would > frequently make the imon VFD go into gibberish mode. If I could feel > any discharge at all, and if it was weak enough to not reboot the > system, gibberish mode happened. Not that I was doing this for fun and > games - I generally tried other discharge means - but sometimes there > was still a little zap left. > > That's still not the whole story, because I've been using > suspend-to-ram, and haven't even touched the system itself in some time > - I power it back up with the remote. But it's still in gibberish mode, > even without me drawing a spark. That's not to say that there may not > be some internal mechanism for throwing noise in there, perhaps on the > ground wire. I haven't looked at the hardware lately - it might be > interesting to see if adding an extra wire to chassis ground would help. Huh, fun. > In any event, does this bugger have a true reset operation? Are the > drivers counting on it being reset by power on, or is there another > reset operation they could invoke, in addition? Perhaps blast it with > near-reset ops, kind of like TV-be-gone. According to http://imonapi.tripod.com/, maybe? -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2010-04-01 20:50:11
|
On Thu, Apr 1, 2010 at 4:26 PM, Jarod Wilson <ja...@wi...> wrote: ... > The other interesting bit I've stumbled on to... The ffdc devices do > NOT support switching ir protocols. Its hard-coded in their firmware > whether they support the imon ir protocol or mce ir protocol. I > *think* I've figured out where in the usb device config struct ffdc > device specifics, like 'has lcd', 'has vfd', 'ir protocol imon', etc > are stored, but I need to code up some debug patches and collect data > for more devices to get a better idea. Don't actually need debug patches (yet). 'lsusb -d 0x15c2: -vvv' output shows the descriptor I think contains the info about the device. For example, with my imon knob: $ lsusb -d 0x15c2: -vvv Bus 003 Device 004: ID 15c2:ffdc SoundGraph Inc. iMON PAD Remote Controller Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x15c2 SoundGraph Inc. idProduct 0xffdc iMON PAD Remote Controller bcdDevice 0.00 iManufacturer 0 iProduct 0 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 41 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 0 (Defined at Interface level) bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 09 21 00 01 00 01 22 25 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 10 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 10 The "** UNRECOGNIZED" line is the one I believe carries device specifics, but I need to look at another ffdc device, and would greatly appreciate it if others could send me the same output from their ffdc devices my way, along with details on what display type and ir protocol its set for. -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2010-04-01 21:25:49
|
On Thu, Apr 1, 2010 at 4:50 PM, Jarod Wilson <ja...@wi...> wrote: > On Thu, Apr 1, 2010 at 4:26 PM, Jarod Wilson <ja...@wi...> wrote: > ... >> The other interesting bit I've stumbled on to... The ffdc devices do >> NOT support switching ir protocols. Its hard-coded in their firmware >> whether they support the imon ir protocol or mce ir protocol. I >> *think* I've figured out where in the usb device config struct ffdc >> device specifics, like 'has lcd', 'has vfd', 'ir protocol imon', etc >> are stored, but I need to code up some debug patches and collect data >> for more devices to get a better idea. > > Don't actually need debug patches (yet). 'lsusb -d 0x15c2: -vvv' > output shows the descriptor I think contains the info about the > device. For example, with my imon knob: > > $ lsusb -d 0x15c2: -vvv > > Bus 003 Device 004: ID 15c2:ffdc SoundGraph Inc. iMON PAD Remote Controller > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 1.10 > bDeviceClass 0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 8 > idVendor 0x15c2 SoundGraph Inc. > idProduct 0xffdc iMON PAD Remote Controller > bcdDevice 0.00 > iManufacturer 0 > iProduct 0 > iSerial 0 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 41 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0x80 > (Bus Powered) > MaxPower 100mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 0 (Defined at Interface level) > bInterfaceSubClass 0 > bInterfaceProtocol 0 > iInterface 0 > ** UNRECOGNIZED: 09 21 00 01 00 01 22 25 00 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0008 1x 8 bytes > bInterval 10 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x02 EP 2 OUT > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0008 1x 8 bytes > bInterval 10 > > > The "** UNRECOGNIZED" line is the one I believe carries device > specifics, but I need to look at another ffdc device, and would > greatly appreciate it if others could send me the same output from > their ffdc devices my way, along with details on what display type and > ir protocol its set for. And a helpful user on #mythtv-users just crushed my hopes. His 0xffdc VFD-equipped iMON has a descriptor 100% identical to the iMON Knob. Sigh. -- Jarod Wilson ja...@wi... |
From: Anders E. <aer...@fa...> - 2010-04-03 07:47:32
|
ja...@wi... said: > Updated patch here, also documents several places where your codes match a > code for something else on another receiver/remote combo: > > http://wilsonet.com/jarod/junk/imon-0xff4xx-keys-v2.patch Doesn't apply cleanly. What should I apply it to? > Starting to think a unified key table might be a pipe dream. Need to get on > the support for remapping keys from userspace. Sounds like a good idea in general for all remotes. From a sysadmin pov remotes should be more keyboard like. Do you kow where i can read up on /dev/input/event? programming? I'd like to get my head around what's needed to make freevo/mplayer use a single code path for both keyboard and remote input (i.e. no (input)lircd in the mix at all). An I guess a part of that is to find out what the input 'focus' architecture is (i.e. what app gets what event based on e.g. VTx used and/or x app having focus). Is that documented anywhere? /A |
From: Jarod W. <ja...@wi...> - 2010-04-03 20:32:25
|
On Sat, Apr 3, 2010 at 3:47 AM, Anders Eriksson <aer...@fa...> wrote: > > ja...@wi... said: >> Updated patch here, also documents several places where your codes match a >> code for something else on another receiver/remote combo: >> >> http://wilsonet.com/jarod/junk/imon-0xff4xx-keys-v2.patch > > Doesn't apply cleanly. What should I apply it to? Its already applied to current git, since version 1 worked well enough for you and it works just fine on my 0x0045 lcd. >> Starting to think a unified key table might be a pipe dream. Need to get on >> the support for remapping keys from userspace. > > Sounds like a good idea in general for all remotes. From a sysadmin pov remotes > should be more keyboard like. > > Do you kow where i can read up on /dev/input/event? programming? I'd like to > get my head around what's needed to make freevo/mplayer use a single code path > for both keyboard and remote input (i.e. no (input)lircd in the mix at all). include/linux/input.h and Documentation/input/* are good places to start. To userspace, keys pressed on an input layer remote are basically indistinguishable from those pressed on a multimedia keyboard, so if an app supports the input layer directly, both Just Work. > An I guess a part of that is to find out what the input 'focus' architecture is > (i.e. what app gets what event based on e.g. VTx used and/or x app having > focus). Is that documented anywhere? Not sure... -- Jarod Wilson ja...@wi... |