I know you can use echo > /proc/empeg_notify to send long buttons, but can the same be done using the EMPEG_HIJACK_INJECTBUTTONS ioctl? If not, is it an easy change to make?

Mmm.. looks like EMPEG_HIJACK_INJECTBUTTONS explicitly forbids long presses.

I could add an ioctl for it, but at this point I'd rather not.

Your app could instead just do:

fd = open("/proc/empeg_notify", O_RDWR);
write(fd, "button stuff", bytecount);
close(fd);

Not very difficult.

Cheers

Sure, it's not difficult, but an ioctl is cleaner, so I thought I'd ask if there was any way to make it work. I'll already have empeg_notify open for other stuff, so I'll just write in a special case for long presses to do that instead of the ioctl.

I'm running into a problem mixing the two approaches.

What I'm trying to do is have my app use the bottom/left/right buttons to navigate an application menu, similar to how the player's menu works -- left/right to select menu entries, down to select them. However, a long press of the bottom button (when the player menu isn't active) is also used to switch info from full-screen to normal.

So, my goal was to bind the bottom/left/right buttons, but when I detect a long press of the bottom button using a timer, send that through to the player as a long press.

If I use your approach, the problem is that the bottom button is bound to my app, so those button presses get eaten instead of passed through.

The only workaround I've found is to unbind from that button, open the FD, write to it, close it, and then re-bind to the button -- I think you can understand that's a bit of a mess.

So, is there any technical problem that would prevent me from adding long-press support to the INJECTBUTTONS call? Why are long presses explicitly forbidden using the ioctl, but available from the empeg_notify interface?

Why not just send everything through the open/write sequence?

(I'm sure there's a reason, by my memory can be poor).

There are several instances in my application where I need to do bind to a button, respond to that button press, and potentially re-send the same button press. So, BINDBUTTONS, POLLBUTTONS, and (conditionally) INJECTBUTTONS depending on application logic.

This particular example is the down/bottom button. I want to use it to pull up an application menu, but in some cases, I need to send a raw "bottom" press through to the player app. The case I mentioned above is the long press, which switches between normal/full-screen info modes. If my app is bound to the bottom button to pull up a menu, I can't then send a long press of the bottom button through to the app using the empeg_notify interface.

I also need to send a short press of the same button through to pull up the player menu from my application menu, but that works fine now since INJECTBUTTONS works with short presses.

Ultimately, once an app needs to bind to a button press, it can't then send that same button press through with the empeg_notify interface -- only the INJECTBUTTONS ioctl can do that.

Okay, that's cool.

Now.. I wonder if any of us can figure out why I originally coded this to expressly forbid long presses ???

If not, I'll enable them, and see what happens.

Oh, waitasec.. on reading the code again, I *think* it actually allows long presses with INJECT. Ditto for BIND.

Just or 0x80000000 with the button code to give a longpress.

Does it work?

Nope, neither seems to work for me. Seeing BUTTON_FLAGS_LONGPRESS in the source, but not in hijack.h, made me think you had kept those out of the header file for a reason. Still, I did try it, and it didn't work.

Is enabling them a one-line (or at least less than 10 line) change that I can make here to save you the trouble?

Try this patch to hijack:

Code:

--- hijack/arch/arm/special/hijack.c.orig       2009-02-11 15:31:48.000000000 -0400
+++ hijack/arch/arm/special/hijack.c    2010-07-27 09:49:15.019820384 -0300
@@ -1227,7 +1227,10 @@
        if (head != q->tail) {
                hijack_buttondata_t *data = &q->data[q->head = head];
                data->button = button;
-               data->delay  = hold_time;
+               if (button & BUTTON_FLAGS_LONGPRESS)
+                       data->delay = LONGPRESS_DELAY;
+               else
+                       data->delay = hold_time;
                if (hijack_ir_debug)
                        printk("%lu: ENQ.%c: @%p: %08x.%ld\n", jiffies, q->qname, data, button, hold_time);
        }

I have the source code here, but not the compiler.

I didn't have a ton of time to test this morning, but I can say that it didn't allow me to inject long presses when I sent this sequence:


It also had strange effects on regular IR usage -- at one point, it seemed to be stuck in a loop where it was repeating one of my IR translate macros. Does that ring a bell as to why you left this out in the first place?

Dunno. Maybe it wants an IR_RIO_INFO_RELEASED code to follow the _PRESSED code ?

Or if that's the case, maybe |BUTTON_FLAGS_LONGPRESS doesn't work and you need to send IR_RIO_INFO_RELEASED longpress-time after you send IR_RIO_INFO_PRESSED?

Right, I can do my own timing delays, but there was already a facility in the kernel for sending long presses, (letting the kernel handle the timing) provided you use the empeg_notify interface. My hope was, that if it wasn't too much work, we could expose that same facility to the INJECTBUTTONS call, but the quick fix appears not to work, and seems to conflict with ir_translate stuff.

I just tried sending:


with a stock v508 kernel and one with the patch above, both to no avail. I guess I'll just handle the timing myself for now.