Hijack dimmer and screensaver suggestion

It'd be cool if hijack had an ac_dimmer setting so that I could set the dimmer in AC mode. By that I mean set it to a specific level in config.ini, not magically make the option appear in the players menu structure. I know I can do it by forcing DC, but sometimes it's nice to have a dim display but do things in AC mode.

And if you're going to write code that can tweak the dimmer setting anyway, it'd be cool to have a two-stage screen saver, the first level of which dims the display instead of shutting it off all the way. It'd be nice to be able to specify both absolute values for the dimmed mode and relative, like screen_dim=30 and screen_dim=-20. Hell, you could put in screen_dim=+20 for some freak out there who's bound to want it to get brighter first. Also timeouts for both modes.

I know that's a big one, but it could be useful.

Yup, that's cool.

Remind me every month or two and eventually..

Cheers

I second Bitt's sentiment, since my spare empeg does duty as a clock radio input.

-Zeke

This would require a few bits of flash though.

I've realised that we might be able to (fairly easily) extend the flash available...at a cost of slightly reduced flash life. Given the rather extreme (6.4million) cycle life expectancy, halving this to gain another 128bits (or 126 if you want to CRC it) of storage is tempting. Of course this does depend on there being enough time at powerfail to store all 256 bytes...

There's two strategies I see for this;

• Writing hijack's block after the player block, 128 bytes lower in memory.
  
  Advantages: The integrity of the player block is ensured by placing hijack's block CRC calculation and flash write after the player flash write.
  
  Disadvantages: Overhead in having two flash writes.
  
  
• Modifying the existing block to be 256bytes long.
  
  Advantages: 2 extra bytes of storage (we only need one checksum). Less overhead by only having one flash write.
  
  Disadvantages: Player block integrity is now codependant on having enough time to write all 256 bytes.
  

If anything, I'd just separate Hijack from the Player in flash -- Hijack settings are updated MUCH less often than the player's (think, "volume"), and could be done with just a single set of flash locations that are overwritten each time.

But for now, we've still got a few bits in the area already set up, and I'm happy to chew those up for worthy features like this. And if expanded memory units become more commonplace, then hijack could just grow by a fair bit of code, and will need corresponding flash to save settings for the new features.

Cheers

What would you need flash for? The settings would be held in config.ini (I don't see any great need to be able to change it from the front panel) and there's not any state that needs to be remembered across boots.

True!

But I'm feeling somewhat more generous (maybe it's the season), and config.ini options are not nearly as nice as on-screen updates.. more memory.. more memory.. bloat.. bloat..

I've forgotten how much we know about the scratch partition. It seems like that's the place that the DC dimmer setting should be kept. Are there spare bits? Can hijack (or something else, for that matter) write to it safely?

Quote:
Can hijack (or something else, for that matter) write to it safely?

Sure, but if the player ever decides to use the scratch partition differently than it currently does, things are broken. I am pretty sure there are entirely unused sectors in between the playlists/bookmarks and the per-FID data, and if not, the sectors in the per-FID area are mostly empty, with only about 60 out of 512 bytes used.