Hijack v256: that blinkin' LED

Hijack v256 is now out.

The only new feature (that I know of, ) is that the infamous and erotic (to some) powerfully pulsating standby LED has been zapped. I'll replace it if many scream, but for the most part I suspect nobody will.

In it's place is a simple blink, once every ten seconds. The duration of the blink, and the interval between blinks, are adjustable in config.ini:

[hijack]

standbyLED_on=1		;; in 1/100ths of a second

standbyLED_off=1000	;; in 1/100ths of a second

It's not perfect. Even the default 1/100th sec blink is too bright for my liking, but to fix it would require a kernel thread running at real-time priority, so that finer resolution could be obtained. If somebody wants to hack one up for me, I'll look at it. Probably 30 lines of C or so.

Cheers

Woohoo!

What a great feature from a guy who supposedly doesn't have time to fuss with Hijack these days. Thanks, Mark.

I like the pulsating LED. As Tony Fabris said, it's like the breathing of a sleeping dragon waiting to be awakened.

Since you read the settings from config.ini, I think absence of such configuration should mean "use Empeg's default" i.e. the pulsating LED.

Please count this as a scream (for optionality at least - I don't want to deprive those who like the change).

Can't the default behaviour continue to be an option? There's a lot of history in that pulsating light - one of the first empeg features ever implemented! My player would certainly cease to be an empeg if that behaviour was lost.

(I don't mind what those new fangled Rio models do, though)

Rob

Okay, two people screamed (very politely, must be British or Canadian ).

I'll change the default back to the pulsating strobing thingie. If one sets standbyLED_on=nn in config.ini, where nn is not -1, then the new behaviour will be activated.

This will be in v257, in a few minutes.

EDIT: so, to get the "new" behaviour, you must now do this in config.ini:

[hijack]

standbyLED_on=1

Cheers

And oh yeah, the ioctl() interface is also now implemented, for those who want to directly control the LED (when display is off) from userland. Use at your own risk.

-ml

Is that really you, Rob?

And oh yeah, the ioctl() interface is also now implemented, for those who want to directly control the LED (when display is off) from userland. Use at your own risk.

Is said ioctl() interface documented anywhere?

I doubt it. It's one of the "stock" Empeg kernel ioctls(), just never did anything before.

To use it, open the display device ("/dev/display" ?), and use the ioctl like this:

int fd = open("/dev/display", O_RDRW);

if (fd != -1) {

	if (0 == ioctl(fd, 1, 0)) {	// enter standby mode

		ioctl(fd, 2, 0);	// turn off LED

		ioctl(fd, 2, 1);	// turn on LED

	}

	close(fd);

}

There are no "seatbelts" here.. so please ensure the display is in standby ("off") before fiddling with the LED.

-ml

You're a nice bloke, Mark.

There are no "seatbelts" here.. so please ensure the display is in standby ("off") before fiddling with the LED.

So are we talking potential hardware damage if not done in the correct sequence?

BTW I'm glad that a binary multiple numbered release like v256 got such a nice feature. Hopefully you've got some real jaw-droppers planned for v512 and v1024!

Should be safe enough with the sequence as shown in my example. But try at your own risk.

I think it is probably safe regardless, as the dangerous stuff is hidden in the kernel code, and always does the Right Thing (tm) in the right sequence.

Hugo mentioned elsewhere that if that part got bunged, then one might end up with two buffers trying to out-drive each other.

-ml

Mmm.. seem to have mungled the ButtonLED illumination code.. Fixed in v258 (shortly).

-ml

They are cool blue sunglasses. And lots of theatrical face paint. And a top hat.

Standard SONICblue corporate dress.

Rob

So, just so i have this straight for the FAQ... the standbyLED_on and _off time periods still apply correct? So as long as _on is any value above -1, then that will be the length of the on blink in 1/100ths of a second. If no _off value is specified, it will blink every 10 seconds. Right?

They are cool blue sunglasses. And lots of theatrical face paint. And a top hat.

And except for the sunglasses, he comes to work every day like that.

Ah.. So, at last.. evidence of a corporate link between SonicBlue and RedHat..

Right.

And it's perfectly legal to disable the LED completely with standbyLED_on=0

Cheers

In reply to:

---

Even the default 1/100th sec blink is too bright for my liking...

---

I have no idea how these things work, but as the original LED code faded in and out, would it be possible to light it at say, 50% brightness? Or was the LED fade controlled by some kind of software PWM or something?

Cheers,

A.

Its a firmware thing, built into the logic that runs the display board. As I noted, one could simulate varying levels of brightness in software, if a faster rate of interrupts were available (the kernel scheduler only guarantees 100 times/sec).

The idea is that LEDs are binary, they are either ON (very bright) or OFF. In-between levels of brightness are achieved by switching the LED on/off very quickly, far faster than the 100 times/sec that is easily available in the kernel.

Cheers

Im not "Screaming" or anything like that but, whenever you get the time mark it would be nice if you could make Visual- work. Right now I have Visual+ when you turn the knob clockwise, and it would be really cool if I could have Visual- when I turn the knob counterclockwise. Im not saying you have to do this right away or even at all, but just making a request. Thanks.

Yes, it's Rob, or at least someone using his admin account to put pictures like that online.

Call me stupid. I don't get it. How do I completely disable that damn led?
I tried standbyLED_on=0 but it still blinks. Then tried -1, same result. What am I doing wrong here?
I'm on v260 BTW. Only discovered it after v256 was gone of course. Does it only work in v256 or what?

Frank

Ditto. This didn't work for me.

Tom

ditto, that's why i haven't put it in the FAQ yet.

Thanks for testing this for me.

Fixed & working now in v261.

Cheers

Thanks Mark!

Frank