From: Jarod W. <ja...@wi...> - 2009-06-18 02:04:24
|
On Wednesday 17 June 2009 21:16:16 Rene Harder wrote: > Hi Jarod, > > > please check the attached patch, It fixes our false mouse event > generation. It works for my device even the scroll emulation is not > effected. I had a similar thought for a fix in my head, looks good. Related to this... > Maybe we should add this for the old imon's as well but I'm > not quite sure if they have the same packet length, do they? ...I finally remembered the clauses just a bit further down in imon_incoming_packet(), where there's an explicit len == 5 check for the newer devices, while the older devices actually do have a len of 8: Recent iMON: if ((len == 5) && (buf[0] == 0x01) && (buf[4] == 0x00)) { Older iMON: } else if ((len == 8) && (buf[0] & 0x40) && !(buf[1] & 0x01 || buf[1] >> 2 & 0x01)) { Those are for handling dpad presses, converting them into arrow key presses when we're in keyboard mode. So yeah, your patch looks to be golden. (I meant to pull that ts_input out earlier, but somehow it managed to survive...). I'll throw this into git and then get started on adding everything to lirc cvs as well... I think we've got a pretty damned solid thing going here now! -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2009-06-18 03:54:15
|
On 06/17/2009 09:47 PM, Jarod Wilson wrote: > On Wednesday 17 June 2009 21:16:16 Rene Harder wrote: >> Hi Jarod, >> >> >> please check the attached patch, It fixes our false mouse event >> generation. It works for my device even the scroll emulation is not >> effected. > > I had a similar thought for a fix in my head, looks good. Related to > this... > >> Maybe we should add this for the old imon's as well but I'm >> not quite sure if they have the same packet length, do they? > > ...I finally remembered the clauses just a bit further down in > imon_incoming_packet(), where there's an explicit len == 5 check > for the newer devices, while the older devices actually do have a len > of 8: > > Recent iMON: > if ((len == 5)&& (buf[0] == 0x01)&& (buf[4] == 0x00)) { > > Older iMON: > } else if ((len == 8)&& (buf[0]& 0x40)&& > !(buf[1]& 0x01 || buf[1]>> 2& 0x01)) { > > Those are for handling dpad presses, converting them into arrow key > presses when we're in keyboard mode. So yeah, your patch looks to be > golden. (I meant to pull that ts_input out earlier, but somehow it > managed to survive...). > > I'll throw this into git and then get started on adding everything to > lirc cvs as well... I think we've got a pretty damned solid thing going > here now! Okay, everything is in cvs now. Have at it, folks! --jarod |
From: Rene H. <re...@sa...> - 2009-06-18 05:11:56
|
Jarod Wilson wrote: > On 06/17/2009 09:47 PM, Jarod Wilson wrote: >> On Wednesday 17 June 2009 21:16:16 Rene Harder wrote: >>> Hi Jarod, >>> >>> >>> please check the attached patch, It fixes our false mouse event >>> generation. It works for my device even the scroll emulation is not >>> effected. >> >> I had a similar thought for a fix in my head, looks good. Related to >> this... >> >>> Maybe we should add this for the old imon's as well but I'm >>> not quite sure if they have the same packet length, do they? >> >> ...I finally remembered the clauses just a bit further down in >> imon_incoming_packet(), where there's an explicit len == 5 check >> for the newer devices, while the older devices actually do have a len >> of 8: >> >> Recent iMON: >> if ((len == 5)&& (buf[0] == 0x01)&& (buf[4] == 0x00)) { >> >> Older iMON: >> } else if ((len == 8)&& (buf[0]& 0x40)&& >> !(buf[1]& 0x01 || buf[1]>> 2& 0x01)) { >> >> Those are for handling dpad presses, converting them into arrow key >> presses when we're in keyboard mode. So yeah, your patch looks to be >> golden. (I meant to pull that ts_input out earlier, but somehow it >> managed to survive...). >> >> I'll throw this into git and then get started on adding everything to >> lirc cvs as well... I think we've got a pretty damned solid thing going >> here now! > > Okay, everything is in cvs now. Have at it, folks! Great, I still have a couple of things on my TODO list (well for several month now ;-) ) which I've not yet investigated further. e.g. display reset, brightness settings, contrast settings , auto adjust, in driver calibration or generating keyboard codes (input event) for the buttons around the d-pad in mouse mode. After merging the touchscreen support into the imon driver, most of this stuff shouldn't be to difficult to implement. What do you actually prefer, patches against CVS or your local git tree. Rene |
From: Jarod W. <ja...@wi...> - 2009-06-18 12:51:49
|
On Jun 18, 2009, at 1:10 AM, Rene Harder wrote: > Jarod Wilson wrote: >> >> Okay, everything is in cvs now. Have at it, folks! > > Great, I still have a couple of things on my TODO list (well for > several > month now ;-) ) which I've not yet investigated further. I know all too well how that goes... > e.g. display reset, Decent chance just sending 0x40 00 00 00 00 00 00 88 to the display via the tx_urb will do the trick. This seems to be the universal reset for the lcd/vfd devices -- resets the display as well as the front- panel buttons and knobs. We do this near the end of imon_probe() for lcd/vfd devices right now. > brightness settings, contrast settings , I hadn't thought to touch these for my device, as lcdproc does this for me... I wonder if it wouldn't make sense to extent the imonlcd lcdproc driver or create a new imontouch lcdproc driver for these types of things -- iirc, lcdproc does support some vga devices already. > auto > adjust, in driver calibration or generating keyboard codes (input > event) > for the buttons around the d-pad in mouse mode. I keep tossing around the idea of sending more keyboard input events when in mouse mode as well. I mean, we might as well -- heck, it would make the remote quite functional without even having to run lircd, let alone have a client connected, which maximizes flexibility and functionality in my mind. At the very least, we could send keyboard codes only in the !context->ir_isopen case, lest we wind up with people confused by the same key doing unexpectedly different things within their app that they've configured to use lirc depending on the toggle state. > After merging the touchscreen support into the imon driver, most of > this > stuff shouldn't be to difficult to implement. > What do you actually prefer, patches against CVS or your local git > tree. Officially, should be against CVS... But I personally prefer git by far. -- Jarod Wilson ja...@wi... |
From: Rene H. <re...@sa...> - 2009-06-18 18:53:40
|
Jarod Wilson wrote: > On Jun 18, 2009, at 1:10 AM, Rene Harder wrote: > >> Jarod Wilson wrote: >>> >>> Okay, everything is in cvs now. Have at it, folks! >> >> Great, I still have a couple of things on my TODO list (well for several >> month now ;-) ) which I've not yet investigated further. > > I know all too well how that goes... > > >> e.g. display reset, > > Decent chance just sending 0x40 00 00 00 00 00 00 88 to the display > via the tx_urb will do the trick. This seems to be the universal reset > for the lcd/vfd devices -- resets the display as well as the > front-panel buttons and knobs. We do this near the end of imon_probe() > for lcd/vfd devices right now. > Need to check my notes but this sequence looks familiar to me but i think with an 81 or 80 in the end. > >> brightness settings, contrast settings , > > I hadn't thought to touch these for my device, as lcdproc does this > for me... I wonder if it wouldn't make sense to extent the imonlcd > lcdproc driver or create a new imontouch lcdproc driver for these > types of things -- iirc, lcdproc does support some vga devices already. That might be a possibility, I'll have a look on lcdproc > > >> auto >> adjust, in driver calibration or generating keyboard codes (input event) >> for the buttons around the d-pad in mouse mode. > > I keep tossing around the idea of sending more keyboard input events > when in mouse mode as well. I mean, we might as well -- heck, it would > make the remote quite functional without even having to run lircd, let > alone have a client connected, which maximizes flexibility and > functionality in my mind. At the very least, we could send keyboard > codes only in the !context->ir_isopen case, lest we wind up with > people confused by the same key doing unexpectedly different things > within their app that they've configured to use lirc depending on the > toggle state. What do you have in mind sending input events for all button on the remote or only the few around the d-pad? We could introduce a modparam so the user can easily control what he wants and still have the flexibility. > > >> After merging the touchscreen support into the imon driver, most of this >> stuff shouldn't be to difficult to implement. >> What do you actually prefer, patches against CVS or your local git tree. > > Officially, should be against CVS... But I personally prefer git by far. Well i guess you'll merge them anyway, so i do what's the easiest for you ;-) |
From: Jarod W. <ja...@wi...> - 2009-06-19 01:16:58
|
On 06/18/2009 02:53 PM, Rene Harder wrote: >> I hadn't thought to touch these for my device, as lcdproc does this >> > for me... I wonder if it wouldn't make sense to extent the imonlcd >> > lcdproc driver or create a new imontouch lcdproc driver for these >> > types of things -- iirc, lcdproc does support some vga devices already. > That might be a possibility, I'll have a look on lcdproc lcdproc/server/drivers/svgalib_drv.c is probably the closest thing, but I'm not sure how close it is... >>> >> ... or generating keyboard codes (input event) >>> >> for the buttons around the d-pad in mouse mode. >> > >> > I keep tossing around the idea of sending more keyboard input events >> > when in mouse mode as well. I mean, we might as well -- heck, it would >> > make the remote quite functional without even having to run lircd, let >> > alone have a client connected, which maximizes flexibility and >> > functionality in my mind. At the very least, we could send keyboard >> > codes only in the !context->ir_isopen case, lest we wind up with >> > people confused by the same key doing unexpectedly different things >> > within their app that they've configured to use lirc depending on the >> > toggle state. > > What do you have in mind sending input events for all button on the > remote or only the few around the d-pad? More than just what's around the d-pad, but not necessarily all of them. A lot of them map pretty well to standard input key names though. Certainly KEY_0-KEY_9, KEY_{VOLUME,CHANNEL}{UP,DOWN}, KEY_MUTE, KEY_PLAY, KEY_STOP, etc. > We could introduce a modparam > so the user can easily control what he wants and still have the flexibility. My thought is that if we do this right, we shouldn't need to. If the user wants to use pure input subsys, they just don't ever open the IR device by way of not firing up lircd. If they want lirc behavior, they fire up lircd and connect an IR client. Not opposed to a modparam though, if it proves worthwhile. Another route would be to make all the keys that are indeed pretty standard always passed in via the input subsystem, and only pass along the less easily universally decipherable keys to lirc. That would probably be worth adding a config param for though -- default to the behavior we have now, but allow the user to say they want as many keys handled by the input subsystem as possible. >>> >> After merging the touchscreen support into the imon driver, most of this >>> >> stuff shouldn't be to difficult to implement. >>> >> What do you actually prefer, patches against CVS or your local git tree. >> > >> > Officially, should be against CVS... But I personally prefer git by far. > > Well i guess you'll merge them anyway, so i do what's the easiest for > you;-) I like the sound of that. :) And at least recently, patches against git are applying reasonably well against cvs too (thanks in no small part to ripping out the kernel 2.4 compatibility crud). --jarod |
From: Rene H. <re...@sa...> - 2009-06-19 02:15:48
|
Jarod Wilson wrote: > On 06/18/2009 02:53 PM, Rene Harder wrote: >>> I hadn't thought to touch these for my device, as lcdproc does this >>> > for me... I wonder if it wouldn't make sense to extent the imonlcd >>> > lcdproc driver or create a new imontouch lcdproc driver for these >>> > types of things -- iirc, lcdproc does support some vga devices >>> already. >> That might be a possibility, I'll have a look on lcdproc > > lcdproc/server/drivers/svgalib_drv.c is probably the closest thing, > but I'm not sure how close it is... > > >>>> >> ... or generating keyboard codes (input event) >>>> >> for the buttons around the d-pad in mouse mode. >>> > >>> > I keep tossing around the idea of sending more keyboard input events >>> > when in mouse mode as well. I mean, we might as well -- heck, it >>> would >>> > make the remote quite functional without even having to run >>> lircd, let >>> > alone have a client connected, which maximizes flexibility and >>> > functionality in my mind. At the very least, we could send keyboard >>> > codes only in the !context->ir_isopen case, lest we wind up with >>> > people confused by the same key doing unexpectedly different things >>> > within their app that they've configured to use lirc depending on >>> the >>> > toggle state. >> >> What do you have in mind sending input events for all button on the >> remote or only the few around the d-pad? > > More than just what's around the d-pad, but not necessarily all of > them. A lot of them map pretty well to standard input key names > though. Certainly KEY_0-KEY_9, KEY_{VOLUME,CHANNEL}{UP,DOWN}, > KEY_MUTE, KEY_PLAY, KEY_STOP, etc. > > >> We could introduce a modparam >> so the user can easily control what he wants and still have the >> flexibility. > > My thought is that if we do this right, we shouldn't need to. If the > user wants to use pure input subsys, they just don't ever open the IR > device by way of not firing up lircd. If they want lirc behavior, they > fire up lircd and connect an IR client. Not opposed to a modparam > though, if it proves worthwhile. > > Another route would be to make all the keys that are indeed pretty > standard always passed in via the input subsystem, and only pass along > the less easily universally decipherable keys to lirc. That would > probably be worth adding a config param for though -- default to the > behavior we have now, but allow the user to say they want as many keys > handled by the input subsystem as possible. > just an idea.. Isn't there an input event driver for lircd? If and we are able to map all buttons to input events, why don't we drop passing them through lirc completely. If the user needs lirc support he can use the input event driver of lircd, or am I wrong about that? > >>>> >> After merging the touchscreen support into the imon driver, >>>> most of this >>>> >> stuff shouldn't be to difficult to implement. >>>> >> What do you actually prefer, patches against CVS or your local >>>> git tree. >>> > >>> > Officially, should be against CVS... But I personally prefer git >>> by far. >> >> Well i guess you'll merge them anyway, so i do what's the easiest for >> you;-) > > I like the sound of that. :) And at least recently, patches against > git are applying reasonably well against cvs too (thanks in no small > part to ripping out the kernel 2.4 compatibility crud). > > --jarod > |
From: Jarod W. <ja...@wi...> - 2009-06-19 04:22:02
|
On Thursday 18 June 2009 22:14:53 Rene Harder wrote: > > My thought is that if we do this right, we shouldn't need to. If the > > user wants to use pure input subsys, they just don't ever open the IR > > device by way of not firing up lircd. If they want lirc behavior, they > > fire up lircd and connect an IR client. Not opposed to a modparam > > though, if it proves worthwhile. > > > > Another route would be to make all the keys that are indeed pretty > > standard always passed in via the input subsystem, and only pass along > > the less easily universally decipherable keys to lirc. That would > > probably be worth adding a config param for though -- default to the > > behavior we have now, but allow the user to say they want as many keys > > handled by the input subsystem as possible. > > > just an idea.. > > Isn't there an input event driver for lircd? So I was originally thinking you were referring to lircd's ability to inject input events, but you're talking about the dev/input, right? (I'll continue here under the assumption it is). > If and we are able to map all buttons to input events, why don't we drop > passing them through lirc completely. > If the user needs lirc support he can use the input event driver of > lircd, or am I wrong about that? I'm not particularly familiar w/lirc's dev/input support myself, but I might see one complication with that approach off the top of my head... To keep the full range of options available, we'd have to somehow map the entire RC-6 protocol. Well, at least all RC-6 signals the iMON can decode onboard. Haven't yet checked to see if they only look for the signals used by MCE remotes or if the full RC-6 proto is supported. There's also a case to be made for not completely altering the basic way lirc has talked to iMON devices for several years, as it could lead to a lot of confusion... -- Jarod Wilson ja...@wi... |
From: Rene H. <re...@sa...> - 2009-06-19 05:07:43
|
Jarod Wilson wrote: > On Thursday 18 June 2009 22:14:53 Rene Harder wrote: > >>> My thought is that if we do this right, we shouldn't need to. If the >>> user wants to use pure input subsys, they just don't ever open the IR >>> device by way of not firing up lircd. If they want lirc behavior, they >>> fire up lircd and connect an IR client. Not opposed to a modparam >>> though, if it proves worthwhile. >>> >>> Another route would be to make all the keys that are indeed pretty >>> standard always passed in via the input subsystem, and only pass along >>> the less easily universally decipherable keys to lirc. That would >>> probably be worth adding a config param for though -- default to the >>> behavior we have now, but allow the user to say they want as many keys >>> handled by the input subsystem as possible. >>> >>> >> just an idea.. >> >> Isn't there an input event driver for lircd? >> > > So I was originally thinking you were referring to lircd's ability to > inject input events, but you're talking about the dev/input, right? > (I'll continue here under the assumption it is). > > I did not meant the uinput support of lirc, that's quit new feature, isn't it. I've never tried that myself. You are right i meant exactly that lircd connects to /dev/input instead of /dev/lirc. I know that lircd supports that, i tried it a couple of years ago with one of my remotes which came with a tuner card. >> If and we are able to map all buttons to input events, why don't we drop >> passing them through lirc completely. >> If the user needs lirc support he can use the input event driver of >> lircd, or am I wrong about that? >> > > I'm not particularly familiar w/lirc's dev/input support myself, but I > might see one complication with that approach off the top of my head... > To keep the full range of options available, we'd have to somehow map > the entire RC-6 protocol. Well, at least all RC-6 signals the iMON can > decode onboard. Haven't yet checked to see if they only look for the > signals used by MCE remotes or if the full RC-6 proto is supported. > I'm not quite sure that I fully understand why there is a problem with the onboard decoder, it should be independent of that. For the imon remotes we have to do the mapping between the imon specific codes and RC6 in the imon driver. If you are using a MCE remote I think it would be enough to forward the onboard decoded RC6 packages to the input subsystem but here I'm not sure if my thoughts are correct. > There's also a case to be made for not completely altering the basic > way lirc has talked to iMON devices for several years, as it could lead > to a lot of confusion... > > That's actually a good point but on the other hand if you always stuck with an old interface it's hard to go newer maybe better ways. |
From: Jarod W. <ja...@wi...> - 2009-06-19 19:06:35
|
On Jun 19, 2009, at 1:35 AM, Rene Harder wrote: >>> >>> I'm not particularly familiar w/lirc's dev/input support myself, >>> but I >>> might see one complication with that approach off the top of my >>> head... >>> To keep the full range of options available, we'd have to somehow >>> map >>> the entire RC-6 protocol. Well, at least all RC-6 signals the iMON >>> can >>> decode onboard. Haven't yet checked to see if they only look for the >>> signals used by MCE remotes or if the full RC-6 proto is supported. >>> >>> >> >> I'm not quite sure that I fully understand why there is a problem >> with >> the onboard decoder, it should be independent of that. >> For the imon remotes we have to do the mapping between the imon >> specific >> codes and RC6 in the imon driver. >> If you are using a MCE remote I think it would be enough to forward >> the >> onboard decoded RC6 packages to the input subsystem but here I'm not >> sure if my thoughts are correct. >> >> > > I think now I understand what you mean, sorry took a bit longer. ;) > > Do you think that is too complicated? I guess it should be possible to > map the hole RC6 protocol to input keys? Yeah, its not so much a case of whether or not it *can* be done, but of whether its going to be a royal pain in the ass to maintain, extend, etc. Right now, if I find another RC6 remote and a button on it that isn't mapped, I can just add it to my local lircd.conf and be done with it. If we do everything via input, I believe I'd have to patch kernel code to make the key useful. Rinse and repeat for who knows how many keys (which is why I think this is far more practical an idea if the iMON receiver only cares about a subset of the protocol, as used by the MCE remotes). > I'm not familiar with RC6 > though, I only know RC5 a little bit more in detail are they much > different? http://www.sbprojects.com/knowledge/ir/rc6.htm covers it pretty well (along with covering numerous other protocols). >>> There's also a case to be made for not completely altering the basic >>> way lirc has talked to iMON devices for several years, as it could >>> lead >>> to a lot of confusion... >>> >>> >>> >> That's actually a good point but on the other hand if you always >> stuck >> with an old interface it's hard to go newer maybe better ways. Certainly. Just saying that we should be cautious, as there's a balance to be struck between technically superior and user-friendly. -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2009-06-21 02:31:44
|
On 06/19/2009 03:08 PM, Jarod Wilson wrote: >> Do you think that is too complicated? I guess it should be possible to >> map the hole RC6 protocol to input keys? > > Yeah, its not so much a case of whether or not it*can* be done, but > of whether its going to be a royal pain in the ass to maintain, > extend, etc. Right now, if I find another RC6 remote and a button on > it that isn't mapped, I can just add it to my local lircd.conf and be > done with it. If we do everything via input, I believe I'd have to > patch kernel code to make the key useful. Rinse and repeat for who > knows how many keys (which is why I think this is far more practical > an idea if the iMON receiver only cares about a subset of the > protocol, as used by the MCE remotes). So I did a bit more digging... - The iMON definitely does NOT decode any RC5 signals, so that helps narrow the window a bit. I don't have any other RC6 remotes around to test with at the moment, but I should be able to set up my Harmony remote to do some sort of RC6. - The ati_remote2 driver in the kernel has support for loadable keymaps, so perhaps it isn't so bad if new decoded values pop up. I'm not exactly sure how it actually works, but I suspect it will be useful to look at that code, particularly in my case, since I've got an ATI Remote Wonder II that I can play with. At the moment, I'd say we proceed slowly and cautiously... First up, lets add support for passing more of the keys to the input subsys when we're toggled into mouse mode (seems slightly backwards, since they're mostly keyboard keys, and we *won't* pass them in keyboard mode, but oh well). Perhaps solicit users for their thoughts on which mode they like better, since they'd essentially be able to use both at once. In related news... I had a user ask if there was a way to disable the mouse mode entirely, as he's never planning to use it (mouse mode isn't so useful for mythtv users, since mythtv hides the cursor and most of the UI doesn't respond to mouse clicks), and if it got toggled on, it might cause some confusion. I'm thinking just a simple modparam to disable/ignore the toggle button. --jarod |
From: Rene H. <re...@sa...> - 2009-06-19 05:35:31
|
Rene Harder wrote: > Jarod Wilson wrote: > >> On Thursday 18 June 2009 22:14:53 Rene Harder wrote: >> >> >>>> My thought is that if we do this right, we shouldn't need to. If the >>>> user wants to use pure input subsys, they just don't ever open the IR >>>> device by way of not firing up lircd. If they want lirc behavior, they >>>> fire up lircd and connect an IR client. Not opposed to a modparam >>>> though, if it proves worthwhile. >>>> >>>> Another route would be to make all the keys that are indeed pretty >>>> standard always passed in via the input subsystem, and only pass along >>>> the less easily universally decipherable keys to lirc. That would >>>> probably be worth adding a config param for though -- default to the >>>> behavior we have now, but allow the user to say they want as many keys >>>> handled by the input subsystem as possible. >>>> >>>> >>>> >>> just an idea.. >>> >>> Isn't there an input event driver for lircd? >>> >>> >> So I was originally thinking you were referring to lircd's ability to >> inject input events, but you're talking about the dev/input, right? >> (I'll continue here under the assumption it is). >> >> >> > > I did not meant the uinput support of lirc, that's quit new feature, > isn't it. I've never tried that myself. > > You are right i meant exactly that lircd connects to /dev/input instead > of /dev/lirc. > I know that lircd supports that, i tried it a couple of years ago with > one of my remotes which came with a tuner card. > > >>> If and we are able to map all buttons to input events, why don't we drop >>> passing them through lirc completely. >>> If the user needs lirc support he can use the input event driver of >>> lircd, or am I wrong about that? >>> >>> >> I'm not particularly familiar w/lirc's dev/input support myself, but I >> might see one complication with that approach off the top of my head... >> To keep the full range of options available, we'd have to somehow map >> the entire RC-6 protocol. Well, at least all RC-6 signals the iMON can >> decode onboard. Haven't yet checked to see if they only look for the >> signals used by MCE remotes or if the full RC-6 proto is supported. >> >> > > I'm not quite sure that I fully understand why there is a problem with > the onboard decoder, it should be independent of that. > For the imon remotes we have to do the mapping between the imon specific > codes and RC6 in the imon driver. > If you are using a MCE remote I think it would be enough to forward the > onboard decoded RC6 packages to the input subsystem but here I'm not > sure if my thoughts are correct. > > I think now I understand what you mean, sorry took a bit longer. ;) Do you think that is too complicated? I guess it should be possible to map the hole RC6 protocol to input keys? I'm not familiar with RC6 though, I only know RC5 a little bit more in detail are they much different? >> There's also a case to be made for not completely altering the basic >> way lirc has talked to iMON devices for several years, as it could lead >> to a lot of confusion... >> >> >> > That's actually a good point but on the other hand if you always stuck > with an old interface it's hard to go newer maybe better ways. > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > > |
From: Rene H. <re...@sa...> - 2009-06-23 17:07:10
Attachments:
input-name-phys-fix.patch
|
Sorry, for my late answer, I was quite busy the last couple of days. Attached you'll find a patch which solve a problem with the input device and physical paths names. Both are pointers and in the old way they pointed to the same address (context->name, context->phys), so mouse and touchscreen had the same name and physical path. Jarod Wilson wrote: > > So I did a bit more digging... > > - The iMON definitely does NOT decode any RC5 signals, so that helps > narrow the window a bit. I don't have any other RC6 remotes around to > test with at the moment, but I should be able to set up my Harmony > remote to do some sort of RC6. > > - The ati_remote2 driver in the kernel has support for loadable > keymaps, so perhaps it isn't so bad if new decoded values pop up. I'm > not exactly sure how it actually works, but I suspect it will be > useful to look at that code, particularly in my case, since I've got > an ATI Remote Wonder II that I can play with. Loadable keymaps sounds interesting, should offer great flexibility and still easy to configure. > > At the moment, I'd say we proceed slowly and cautiously... First up, > lets add support for passing more of the keys to the input subsys when > we're toggled into mouse mode (seems slightly backwards, since they're > mostly keyboard keys, and we *won't* pass them in keyboard mode, but > oh well). Perhaps solicit users for their thoughts on which mode they > like better, since they'd essentially be able to use both at once. I agree, better no rush. > > In related news... I had a user ask if there was a way to disable the > mouse mode entirely, as he's never planning to use it (mouse mode > isn't so useful for mythtv users, since mythtv hides the cursor and > most of the UI doesn't respond to mouse clicks), and if it got toggled > on, it might cause some confusion. I'm thinking just a simple modparam > to disable/ignore the toggle button. > I do use mythtv as well, but i need the mouse function because every now an then i switch to my Desktop. (the UI does respond to mouse clicks otherwise the touchscreen wouldn't work, it's just hiding the cursor) I think a modparam will be an easy way to solve this problem. Well you already implemented it :D |
From: Jarod W. <ja...@wi...> - 2009-06-30 05:19:09
|
On Jun 23, 2009, at 1:07 PM, Rene Harder wrote: > Sorry, for my late answer, I was quite busy the last couple of days. No worries, we all get busy sometimes (myself included the last few... :) > Attached you'll find a patch which solve a problem with the input > device > and physical paths names. Both are pointers and in the old way they > pointed to the same address (context->name, context->phys), so mouse > and > touchscreen had the same name and physical path. Gah, whoops, yeah, that's not so good. I'll get that committed tomorrow. ... >> In related news... I had a user ask if there was a way to disable the >> mouse mode entirely, as he's never planning to use it (mouse mode >> isn't so useful for mythtv users, since mythtv hides the cursor and >> most of the UI doesn't respond to mouse clicks), and if it got >> toggled >> on, it might cause some confusion. I'm thinking just a simple >> modparam >> to disable/ignore the toggle button. >> > I do use mythtv as well, but i need the mouse function because every > now > an then i switch to my Desktop. (the UI does respond to mouse clicks > otherwise the touchscreen wouldn't work, it's just hiding the cursor) > I think a modparam will be an easy way to solve this problem. > > Well you already implemented it :D Yep, turned out to be pretty simple, requesting user is happy as can be. As for sending more input data... I'm on vacation for a few days starting Wednesday, doubt I'll have time to work on much of anything until at least the week after, and there's something else of higher priority I'd like to get done before we get lirc 0.8.6 out the door[*], so if you want to have a go at the imon input stuff, please feel free. [*] attempting to add support to lirc_mceusb2 for the single device supported by lirc_mceusb right now. -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2009-07-02 13:34:17
|
On Tuesday 30 June 2009 01:20:10 Jarod Wilson wrote: > > Attached you'll find a patch which solve a problem with the input > > device > > and physical paths names. Both are pointers and in the old way they > > pointed to the same address (context->name, context->phys), so mouse > > and > > touchscreen had the same name and physical path. > > Gah, whoops, yeah, that's not so good. I'll get that committed tomorrow. Or maybe tomorrow's tomorrow. Got tied up again... Beat on lirc_mceusb2 a bunch tonight, inching closer to functionality w/the first-gen device, but now well past my bed time... -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2009-07-06 02:33:16
|
On 07/02/2009 02:38 AM, Jarod Wilson wrote: >>> Attached you'll find a patch which solve a problem with the input >>> device >>> and physical paths names. Both are pointers and in the old way they >>> pointed to the same address (context->name, context->phys), so mouse >>> and >>> touchscreen had the same name and physical path. >> Gah, whoops, yeah, that's not so good. I'll get that committed tomorrow. > > Or maybe tomorrow's tomorrow. Got tied up again... Hey Rene, Sorry for the delay, finally got it committed a few minutes ago. --jarod |
From: Jarod W. <ja...@wi...> - 2009-07-04 05:28:23
|
On Jul 2, 2009, at 2:38 AM, Jarod Wilson <ja...@wi...> wrote: > Beat on lirc_mceusb2 > a bunch tonight, inching closer to functionality w/the first-gen > device I've now got IR receive 100% functional using a first-gen mceusb receiver with the mceusb2 driver, so the old driver will be going away soon. Internet access is horrible here (yes, I'm spending part of my vacation by hacking on lirc...), so it won't officially show up for a few more days. No regressions w/the 2nd-gen receiver either, fwiw. All testing done w/a Motorola DRC800 remote thus far, and haven't yet tried xmit on the older device, but it can't regress, since it never worked before either... :) --jarod |
From: Jarod W. <ja...@wi...> - 2009-07-05 21:34:25
|
On 07/04/2009 01:27 AM, Jarod Wilson wrote: > On Jul 2, 2009, at 2:38 AM, Jarod Wilson<ja...@wi...> wrote: > >> Beat on lirc_mceusb2 >> a bunch tonight, inching closer to functionality w/the first-gen >> device > > > I've now got IR receive 100% functional using a first-gen mceusb > receiver with the mceusb2 driver, so the old driver will be going away > soon. Internet access is horrible here (yes, I'm spending part of my > vacation by hacking on lirc...), so it won't officially show up for a > few more days. No regressions w/the 2nd-gen receiver either, fwiw. All > testing done w/a Motorola DRC800 remote thus far, and haven't yet > tried xmit on the older device, but it can't regress, since it never > worked before either... :) Also tested with a Windows Media Center Ed. remote, works great there too. Haven't tested out xmit, but meh. Its all in cvs now, as well as in my git tree. Will get around to xmit testing sometime soon, but its not particularly high priority to me, so if you've got a 1st-gen mceusb device and can test xmit support, that would be appreciated. -- Jarod Wilson ja...@wi... |