Bugzilla – Bug 2094
press and hold of front panel buttons doesn't work
Last modified: 2006-10-11 14:21:36 UTC
Who should this belong to?
KDF: Since I don't have a transporter to test this on, can you look at it?
will do. first impression was that it would be a firmware problem, but I can get a real idea of what is going on now.
Subject: Re: press and hold of front panel buttons doesn't work Thanks. One thing to notice from the Front_Panel.ir is that we send separate down and up events for the front panel controls rather than repeats as an IR remote would. This means that we can quickly and accurately determine the duration of the button press without having to use the heuristics in the IR code.
One option will be to always wait for the *.up event, timing from the initial event. On release, we get *.single or *.hold_release. I guess *.hold could be done via a timeout, if the *.up event isn't seen. It is easy if all you want is short vs long press, but an extended hold or continuous while hold would be more complicated.
Subject: Re: press and hold of front panel buttons doesn't work Well, for buttons that only deal with a .single, then the down event should do the trigger. For ones that handle more then we'll have to wait until the .up. Continuous hold is harder because we'd have to generate the repeat codes on the server (and know that they were front panel buttons, i.e. they had an .up code and set up timers for them...)
*** Bug 3886 has been marked as a duplicate of this bug. ***
I see what you are saying, but I'm not sure it can work easily this way without reworking the whole ir processing. I may be missing something in the *.single detection, but it seems to be a mapping feature and we only check this AFTER dealing with the IR. For Transporter, we don't know if *.single has any function until we look into the map. Iight now .single seems to get issued whther it is of use or not. I was thinking more along the lines of: On Press: issue play & play.down, begin a holdtimer set to expire at holdtime. If holdtimer expires: issue play.hold and enter "holding" state. On Release: issue play.up event. if the holdtimer still exists, issue play.single & kill timer. If holdtimer expired and in "holding" state, then issue play.hold_release. it could be possible to add "repeat" timers to issue interim events where needed, and yes, only for buttons that have a .down and .up code.
Adrian, you worked on the IR queuing recently, so any thoughts on this? That is, if any memories of IR-land remain.
I'd be tempted to rename the IR codes so they are specific for the font pannel - ie. *.down and *.up. We can then process this in an entirely different way from normal IR. However I would suggest kicking off a timer on the normal repeat rate (~100ms) so that repeat codes could be generated. Let me know if I want me to look at this.. Also also need to know what the firmware does if multiple buttons are pressed - can we get overlapping *.up and *.down codes?
I like that idea. I was getting stuck trying to figure out how/where to split off from the handling. This makes it easier to split as soon as we see the .down. I suspect buttons will overlap, but I'll test for sure shortly. I'm also now wondering why the difference in "volumemode" and "volumego.up". I'll proceed using "volumemode.down" and "volumemode.up" as a pairing.
thankfully, firmware only responds to one button down at a time :)
Created attachment 1449 [details] looking for input This still needs more comments and hardening, but I'd like to have some comments on the implementation so far: any pitfalls already? This does't yet implement a repeat cycle, but I got the impression that this wasn't the initial priority going from Dean's comment. I'm not sure if any of the front buttons really benefit from repeat at this point, and it would make things more complex and add burden with the handling of more timers. is a .double implementation critical?
Subject: Re: press and hold of front panel buttons doesn't work Ideally, the front panel buttons would behave just like (or better than) the remote buttons, with repeat, hold, release, etc... That said, since up/down are handled by the knob, I don't think repeat is an issue right now.
Created attachment 1451 [details] better version after testing This now works with all of the panel. I've tested play.hold and pause.hold and they work. Search and Browse even work with the patch I have in for another enhancement to toggle through the browse and search options.
Created attachment 1452 [details] including ir file changes forgot the changes to Front_Panel.ir in the other two.
Subject: Re: press and hold of front panel buttons doesn't work Sweet. Can't wait to get a Transporter to try it on. :) Please commit so the other folks can.
This is looking good to me. If you add a timer for repeat, we also need logic to kill it off if the slimproto session disconnects in case you loose the up message. So this is probably the simplest thing for the moment.
Since I can't see the function of a repeat for any of the front buttons in standard use, I'd vote that the repeat tiing is something that should be punted to post 6.5. I'll go over the patch a bit more, put in some comments and commit shortly. Will then re-title this bug for the later work.
Press and hold pause does not perform a stop function at present.
really? it works for me. when I can merge this in, see what you find in the d_ir debug if it is still a problem. i'e got several patches going to it could be possible that I need more changes from other places
WAS working. not now. Will fix before merging.
committed at change 9070. Will leave this open for now. Please test. pause.hold should be working now.
Chris to verify it's fixed.