Rockbox Technical Forums
Rockbox Development => Feature Ideas => Topic started by: BoxArockin on February 18, 2009, 12:01:33 AM
-
Would it be possible to disable (not show) the FM radio application via a config file setting, etc. even though the hardware has the tuner chip available?
-
Why?
-
ie. parental controls (a lot of junk out there on the radio these days I would not necessary want my young kids stumbling across at their age), etc.
Here are some threads with others' reasons:
http://www.anythingbutipod.com/forum/showthread.php?p=267860
http://www.misticriver.net/forums/iriver-h3xx-series-h320-h340/41162-can-i-disable-radio-function-h340.html#post440753
-
I don't think this is very likely to be accepted to SVN, but you could try to compile your own build (http://www.rockbox.org/twiki/bin/view/Main/DevelopmentGuide) with the radio disabled.
I'm not sure, but I think removing all the blocks of #if CONFIG_TUNER
...
#endif from rockbox/apps/root_menu.c might work.
-
Why not simply remove the CONFIG_TUNER define, then?
-
Tried that first, but a bunch of code in rockbox/firmware/target/arm/sandisk, I think, didn't like that. Doing the above gets it to compile, at least. I don't have my e200 on me, so I couldn't actually test it.
-
Did you compile in a different folder than usual (or make veryclean)?
-
Yes, a new directory. I've just retraced my steps. Above, I gave the wrong folder (rockbox/firmware/target/arm/sandisk) for the error messages from removing that define.
Here are the errors from removing #define CONFIG_TUNER LV24020LP from firmware/export/config-e200.h...
CC apps/menus/playlist_menu.c
CC apps/menus/recording_menu.c
/home/anthony/rockbox/apps/menus/recording_menu.c: In function ‘recsource_func’:
/home/anthony/rockbox/apps/menus/recording_menu.c:89: error: ‘LANG_FM_RADIO’ undeclared (first use in this function)
/home/anthony/rockbox/apps/menus/recording_menu.c:89: error: (Each undeclared identifier is reported only once
/home/anthony/rockbox/apps/menus/recording_menu.c:89: error: for each function it appears in.)
/home/anthony/rockbox/apps/menus/recording_menu.c:89: warning: missing initializer
/home/anthony/rockbox/apps/menus/recording_menu.c:89: warning: (near initialization for ‘names[1].string’)
/home/anthony/rockbox/apps/menus/recording_menu.c:95: warning: implicit declaration of function ‘radio_hardware_present’
make: *** [/home/anthony/build-sansae200/apps/menus/recording_menu.o] Error 1
rm /home/anthony/build-sansae200/apps/bitmaps/native/usblogo.128x37x16.c /home/anthony/build-sansae200/apps/bitmaps/native/default_icons.6x8x16.c /home/anthony/build-sansae200/apps/bitmaps/native/rockboxlogo.176x54x16.c
So then I took a punt and also removed #define HAVE_TUNER_PWR_CTRL and | SRC_CAP_FMRADIO from config-e200.h, and got the following. The first time, I didn't start again with a different directory at this point, but when retracing my steps just now, I did (or rather, deleted and recreated the same directory name), with the same effect.
...
CC firmware/target/arm/sandisk/sansa-e200/powermgmt-e200.c
CC firmware/target/arm/sandisk/audio-c200_e200.c
/home/anthony/rockbox/firmware/target/arm/sandisk/audio-c200_e200.c: In function ‘audio_input_mux’:
/home/anthony/rockbox/firmware/target/arm/sandisk/audio-c200_e200.c:72: error: ‘AUDIO_SRC_FMRADIO’ undeclared (first use in this function)
/home/anthony/rockbox/firmware/target/arm/sandisk/audio-c200_e200.c:72: error: (Each undeclared identifier is reported only once
/home/anthony/rockbox/firmware/target/arm/sandisk/audio-c200_e200.c:72: error: for each function it appears in.)
make: *** [/home/anthony/build-sansae200/firmware/target/arm/sandisk/audio-c200_e200.o] Error 1
rm /home/anthony/build-sansae200/apps/bitmaps/native/usblogo.128x37x16.c /home/anthony/build-sansae200/apps/bitmaps/native/default_icons.6x8x16.c /home/anthony/build-sansae200/apps/bitmaps/native/rockboxlogo.176x54x16.c
anthony@blahblah:~/build-sansae200$
So then I gave up that route and removed the #if CONFIG_TUNERs from root_menu.c, which worked.
-
I'm probably going to sound like a moron here, but: you could also try building an fmpresets file that contains only the stations you want them listening too... i believe the format is "XXXX000000:STNM Station Name" where the Xs represent the frequency, and STNM the call letters
-
It is trivially easy (one button press) to switch from preset to manual mode, so that on its own will not help I don't think.
-
Of course, no mater what you do in RockBox, the user could simply boot into the original firmware and use the radio from there. You'd have to somehow disable it in the OF. If you flash using an OF without radio, the person you are trying to censor can always flash it back.
Censorship can always be circumvented by the determined.
-
Maybe I'm just an idiot, but if people are that worried about their kids listening to the radio maybe it would be more practical to buy a device without such capability? Or monitor how much the kids use it? Or if you want to be really paranoid you could open the device up and physically disconnect the antenna. But honestly parental control software does not protect children. Good parenting protects children.
Now, from a more practical standpoint, disabling the radio because of a hardware problem (like the antenna connection on the chip broke), or because you simply don't use the radio (ever) and want to take it out of the menu... that I can see as being a justifiable reason for this request.
-
maybe it would be more practical to buy a device without such capability?
e200s are pretty cheap (although the OP hasn't specified which player this is for). Or monitor how much the kids use it?
Even assuming this is practical (which it isn't), I imagine being followed around by a parent who is making sure you are only listening to certain radio stations might be much more frustrating than having no radio at all. A lot of the time, I like to relax, lie down, and listen to music alone, with my eyes closed. How would this omnipresent parent affect that?
Or if you want to be really paranoid you could open the device up and physically disconnect the antenna.
Because that's somehow a better solution than just disabling it in software? ??? But honestly parental control software does not protect children. Good parenting protects children.
I'm pretty sure the OP thinks they are doing the latter by doing the former.
As I am now, there's no way I would ever censor the radio myself, but people keep telling me everything changes when you have your own kids, and this is definitely something for the parent to decide, not you.
-
I wasn't proposing following the kids around and taking the headphones away from them every few minutes to check what they're listening to. Clearly that's a bad idea. I was thinking more along the lines of just keeping an eye on how many hours a day does the kid walk around with the headphones in.
But how about explaining to your kids what your expectations of good behaviour and acceptable music are and trusting them to be responsible? Check how often they have their headphones on. If it's 24/7 maybe mention that they should take a break? Or if they're obviously enjoying what they're listening to why not ask them what it is they're listening to that they enjoy so much. Active, interested, involved parenting seems to be a better solution than disabling features because you don't think your children can be trusted with them.
Anyway, that's enough of my views on parenting. As I said, there are other legitimate reasons for wanting to disable the radio. I don't know how many people will actually need/want this functionality, but I suppose it's a good option to have around.
-
As long as there are legitimate reasons for a feature I don't think it's productive to micromanage every user's reasons for wanting it. (Also, this isn't a parenting forum. ;)) However, I expect that the most that would likely be done about this is to make it easier to disable at compile time.
-
ve4cib, I don't think the issue was how much the DAP's being used, but *how* it's being used - I got the impression that certain radio stations in the area are not "family friendly".
-
Please, stop discussing the why. If anyone has anything to add to the how, then please do, but nothing more on parenting etc.
-
I'm in agreement that the easiest way of doing this would be to disable it at compile-time. Either you want the radio disabled or you do not. I can't see much reason for wanting to arbitrarily switch it on and off, so disabling it at compile-time should be sufficient. Besides, that will free up that tiny bit of extra memory for other (more useful?) things.
Something else that just occurred to me (and is arguably way more work than it would be worth)....
What about some sort of password-protected locking feature on the device? If you have certain folders that contain private data, or you share your device with someone else and you don't want them knowing what radio presets you happen to enjoy this might be useful.
Essentially every program (plugins, and core functions) could have a "Lock this feature" and "Unlock this feature" functionality. The easiest place for this to appear would probably be in the context menu. To unlock you'd be prompted with the on-screen keyboard where you'd type in a password. Provided the password is correct you'd be allowed to use the function. An "Auto-lock this feature" might also be useful; you have to unlock it every single time you want to use it.
Obviously this would require a fair bit of coding if you want the password to be secure (you'd need a secure way of storing the password), and you would need to add the Lock/Unlock checking to... well, pretty much everything. I haven't actually looked at the code so I don't even know how feasible this would be.
-
What about some sort of password-protected locking feature on the device? If you have certain folders that contain private data, or you share your device with someone else and you don't want them knowing what radio presets you happen to enjoy this might be useful.
This has been suggested many times before. Its been rejected since its trivial to mount any rockbox device in UMS mode and reset the settings.
-
For the issue at hand though all we need to do is have a secure password when you want to enable a certain feature. The implementation doesn't need to be bullet-proof, but it can be made "good enough."
This is maybe getting overly complicated, but please bear with me...
1- add a "LOCK_FEATURES" flag at compile-time. If this flag is enabled then you will be promted at compile-time you specify what features will require password-protection.
2- at compile-time you are prompted to enter the password. This password cannot be changed unless you recompile
3- store the password as a read-only encrypted hash in the flash memory/boot-loader portion of Rockbox.
4- when you attempt to use a locked feature you are prompted for a password. You enter it, its secure hash is calculated and compared to the one generated at compile-time.
5- if the password is OK then you can use the feature. It remains unlocked until you power-off the device
Yes, you can mount the device, but all the settings are compiled-in; you can't change anything by mounting it without re-compiling Rockbox and re-installing it. And you can't read the password file since it's an encrypted hash (same kind of idea as the password files on Linux systems). You could brute-force or reverse-engineer the password, and changing the password is very inconvenient, but it should offer feature-locking that's good-enough for most purposes.
For the hash portion one could presumably use the md5 plugin that's already generated. md5 is slightly deprecated, but we're not talking about storing state secrets.
Protecting entire folders, as you point it, is not really viable on media players since you can mount the device and read it anyway. But for locking specific features I think should be possible to do it with password-protection on the off-chance that you want to simply keep certain users from accessing a given feature, rather than leaving the feature compiled-out.
-
So any time a config file is loaded (every boot of the player) that contains settings that aren't allowed to change *from the original default* a password is needed?
This would basically mean to use the player if you changed any of these settings from the default, you'd need to put in the password every boot.
-
I honestly don't know if that would be the case or not. As I said, I haven't looked at the code, so I don't know what the architectural changes would have to be to let that kind of password-protected feature lockdown occur. I was just throwing ideas out there for discussion.
I was working under the assumption that launching a plugin and loading the plugin were two different things. You load everything at startup, but when you actually go to execute something that's locked-down you're prompted for a password.
If, for example, you choose to lock down Solitaire you you would be prompted for a password the first time you launch Solitaire from the Games menu after booting up. If you lock down the mpeg plugin you'd be asked for a password the first time you try playing a movie since your last boot. And so on with every other locked feature.
-
I was talking about the settings aspect, not the plugins aspect. You are aware that settings are saved in a .cfg file, which is then loaded upon boot, and that other .cfg files can be loaded? Thus if any setting is "protected" any time a .cfg file changed it (such as restoring your settings, every boot) it would request the password.
Not to mention, plugins really are plugins. If someone wanted to they could just download our version of the plugin here and play the unprotected version.
-
I'm not entirely sure I follow what you're saying...
Settings are stored in a .cfg. Fine. I don't see why that's an issue. Why would you ever be prompted for a password when loading settings? It's not the settings that are protected. It's the actual launcher that would require the password. Unless the radio or mpeg plugin is actually executed during startup then you shouldn't get a prompt until you actually go to the menu and launch that feature.
Not to mention, plugins really are plugins. If someone wanted to they could just download our version of the plugin here and play the unprotected version.
Plugins are plugins... yes. Yes they are. I don't understand your point.
And yes, to get around the password protection on a given feature you could always reinstall the system. But to get around a compiled-out radio feature you could do the same thing. So the level of security is the same between the two.
-
Your original description talks about being able to disable every FEATURE, not just plugins. So I discussed it in relation to all the non-plugin features (settings being the vast majority of them).
I don't see why you're confused by this, unless you really meant "just plugins" and your earlier post was misleading.
-
So the level of security is the same between the two.
And unsurprisingly, both will never be accepted into SVN.
-
Your original description talks about being able to disable every FEATURE, not just plugins. So I discussed it in relation to all the non-plugin features (settings being the vast majority of them).
I don't see why you're confused by this, unless you really meant "just plugins" and your earlier post was misleading.
I was using the term "Feature" to describe only the plugins. I meant the "features" that get advertised to the end-user (things like radio, mpeg players, text viewers, games, etc...). Bad wording on my part I suppose.
And unsurprisingly, both will never be accepted into SVN.
Well I guess that pretty much wraps this thread up then doesn't it?