True, I thought about that... But it'd be nice if the kernel "released" that button when a user app is selected so that it can pass through to the player. *Especially* if you're running the app in overlay mode.

...or looking at it from another angle having the kernel hold onto the button gives you an escape route from a badly behaving userland app...

Yeah but in its current incarnation, it doesn't give you an escape route at all unless the app specifically returns control when it receives that button, i.e. it binds to and looks for that button. So right now there seems to be no good reason the kernel is holding onto it.

Not being able to push the "play/pause" front panel button kind of defeats the purpose of having userland apps which can overlay on the screen. I don't think this was left in intentionally.

I'd like to post a wish for Mark King Kernel Hijack.

I had a problem when I tried to sz Stick Figure Fight, and i entered in Hijack Menu to reboot.

But I hadnt ro, rom.

So, if not already done, is it possible to make partition ro before rebooting sequence.
I could be very useful when you crash the shel and cannot ro the partiotion.

I am having trouble getting the player to switch between player and tuner mode using a long press of my source buttons

[ir_translate]
00AD520A=0020DF13 ; volume up
00AD520B=0020DF17 ; volume down
00AD520C=00000008 ; Knob press/ATT
00AD5212=0020DF14 ; info/Band
00AD521A.LM=0020DF07 ; tuner/ long player source
00AD521A.LT=0020DF03 ; player/ long tuner source
00AD512A=0020DF14
00AD5240=0020DF0C ; up/cancel
00AD5242=0020DF10 ; left/left
00AD5243=0020DF11 ; right/right
00AD5241=0020DF12 ; down/menu
00AF5067=0020DF0D ; func/shuffle
00AD520D=0020DF02 ; audio/source


Anybody got a clue as to my goof up

>observation that hijack's BINDBUTTONS ioctl always
>intercepts (hijacks) the top front-panel button

Err.. It does not do that for me..
But it might be a good idea to also intercept the button RELEASE code at the same time, to avoid strange side-effects of a button release arriving in the menu/player with no corresponding PRESS code.

On a related note, you can intercept EVERYTHING by just passing an empty buttonlist.

Cheers

>when you're in the equalizer screen, and you tap the knob, it brings up the VolAdj. Oops.

I'll fix that sometime this week.

-ml

Whoa, he's BACK!

before you write anything how was the holiday welcome back

Err.. It does not do that for me..

Are you sure? I wrote a small test which just intercepts knob left, knob right, and knob pressed. When I try to press the top button, nothing happens.

Here is the bind array I used:

unsigned long data=0, buttons[4] = {4,
IR_KNOB_PRESSED,
IR_KNOB_LEFT,
IR_KNOB_RIGHT
};

Wonder what else could be causing it?

Err.. perhaps I don't understand the issue.. but if your sample program wants to do something on presses of the TOP button, then it will need to have IR_TOP_BUTTON_PRESSED in the buttons[] array..

The "calculator" code within hijack does exactly this, using a buttons[] list to intercept several codes including the TOP button, taking special action when it is pressed. Works perfectly. (see the calculator_display() function for details).

Cheers

-ml

>before you write anything how was the holiday welcome back

Ooops.. too late. I put v74 and v75 out yesterday.

But the trip was fun. Jane & I used 240000 frequent flyer points to fly First Class to New Zealand (United Airlines International FC highly recommended!). Once there, we rented a car and drove around much of the main North and South Islands, taking in the scenery and local wines. Good fun, though we didn't see much down south, since it poured rain most days when we were anyplace near the Southern Alps. But we did manage a bit of rock climbing on both Islands -- I'll be updating the pics on my main webpage shortly.

Cheers

-ml

I spent far too brief a period in new zealand and loved the place i would love to go back some day it is a bit like scotland on steroids with better weather.

I managed to just catch the run up to the americas cup there in auckland one time when i paid off a ship

Once you have got yourself organised i am not getting long presses to work with my pioneer remote

Also i will admit to a Goof the codes i posted for the pioneer remote are wrong as when you use hijack to display codes if you have those codes altered the translated codes are translated i will get the right codes to you asap

Thanks for all the good work

Paul

I think the current versions of Hijack now only display the raw (untranslated) codes, if that helps any.

Nonono I do NOT want it to intercept the top front panel button, but it IS intercepting it and blocking it from being sent to the player. I don't have problems intercepting the top button, but when I *don't* want to intercept it, it gets intercepted anyway.

Oh. I see.

Well, I don't know whether or not it would be good (or bad) to change this behaviour in hijack.. have to think on that one a bit. But in the meanwhile (and long-term), you could just intercept both the press/release for TOP button, and then just use EMPEG_HIJACK_INJECTBUTTONS to pass them along to the player. That will work regardless of what eventually happens within the hijack core.

Cheers.

Yeah I thought of that, that's my temporary workaround. :) Just curious why you think it might be undesirable to NOT intercept the top button? I know that's what you use in the menus to cancel out, but why not let that button go through to the player when the user apps are active?

Otherwise, having an app use the overlay functionality is useless, because it will render the top button useless... right?

Probably right. But I only just got back, and my slow mind doesn't want to mess anything up right away.

Hey, I hear ya... Take your time. I have other Empeg fish to fry, as my many posts here illustrate.

Okay, it's out there.. v76. The only new thing about this release is that all button presses are just passed on transparently when a userland app is being run from hijack (top button, and others also..).

Works quite well, as advertised. One thing I noticed though... When one of my user apps is running, it seems to somehow interfere with the player's ability to spin down the hard drives. Any clue why? Theoretically when my user apps call WAITMENU to return to the menu, they should just be sitting around sleeping, right? Well it seems that when my trivia game or any of my other hijack prototypes are running, the disks don't spin down. This is quite undesirable in the car... Just wondering what might be causing this.

This is not new behavior, I've noticed it for awhile but never got around to mentioning it here.

>When one of my user apps is running, it seems to somehow interfere
>with the player's ability to spin down the hard drives.

That happens because the player itself likes to control drive spin up/down, rather than leaving it to the operating system. That works very well, so long as the player is the only app running..

In your case, I bet if you don't touch any controls until after the next time the player reads a new track, the drive will then spin down.. kinda not too useful to you, though.

This here will fix it for both you and the player: hdparm -S1 /dev/hda

Cheers

-ml

I'll give that hdparm command a shot... thanks.

Okay I just read Hugo's followup to the hdparm -S1 suggestion and it seems that's not entirely a good idea.. So where does that leave us?

I think that we could probably add a config.ini option which would prevent the player from doing spindown (it'd still do idlenow's when it wanted the disk). This would allow 3rd party apps to use the HDDs normal idle timeout and not upset the player (or vice-versa)

I'll enter it as a task in our task system; it should be pretty easy to add.

Hugo

Hey Mark, how about a little feature request? I would love to be able to feed a group of ir codes to the player when it first starts up. This would allow us to force the player to startup into a known state every time. Examples of how this would be useful...

* Force player to always start in tuner/player/aux mode
* Always decrease volume when player starts
* Always press down button to go to visual mode
* Always play a startup mp3

What do you think? Would it be possible to inject some startup codes into the ir stream for the player to read when it first starts with your ir stuff?

-Mike

>Okay I just read Hugo's followup to the hdparm -S1 suggestion
>and it seems that's not entirely a good idea..

No, I believe Hugo was just explaining why the player software cannot rely on "hdparm -S1" for its needs. Most (all?) other userland apps could easily be handled by this, on top of what the player already does (the two should not be in conflict).

Cheers

In reply to:

---

Hey Mark, how about a little feature request? I would love to be able to feed a group of ir codes to the player when it first starts
up. This would allow us to force the player to startup into a known state every time. Examples of how this would be useful...

* Force player to always start in tuner/player/aux mode
* Always decrease volume when player starts
* Always press down button to go to visual mode
* Always play a startup mp3

What do you think? Would it be possible to inject some startup codes into the ir stream for the player to read when it first starts
with your ir stuff?

---

No problem here in doing it, EXCEPT FOR.. it is very difficult to ensure the init presses get done before the player does anything else.. so the previous track may start playing before your init presses get processed to cause a startup tune or whatever.

But for many purposes, this ought to work fine.
This would just be for player-powerup, right? But what if the player was in "standby" before powerdown.. in which case it will normally want to go back into standby on powerup.. We wouldn't want to do the init then, would we? Not sure if this can be detected reliably, either..

?

what if the player was in "standby" before powerdown.. in which case it will normally want to go back into standby on powerup.. We wouldn't want to do the init then, would we?

Maybe, maybe not. What if the purpose of the startup codes was to make sure the player never turned on and then went to sleep? I never really understood the logic behind that anyway, if I just plugged the unit in don't I probably want to listen to music now? Otherwise wouldn't I have just left it unplugged?

-Mike

The purpose is more along the lines of, I just got back into my car and started the engine, why the heck is my player suddenly now playing the next tune in the playlist, even though my amp (separate tuner/cd player) is turned off?

Got it?