After seeing a few posts in the forums asking about the /dev/rtc error that
mplayer gives if it cannot use RTC hardware timing, It occured to me that this
issue could be fixed in the ebuild.
I am not a coder. I know I am not fully qualified to impliment this change, or
evaluate the implications & repercussions if it was implimented.
That being said, I think it would help out some folks if the ebuild for MPlayer
checked the permissions on /dev/rtc & /dev/misc/rtc for read rights for non-
root users, and adjusted them accordingly (say 644).
It is also IMO benificial to adjust /etc/sysctl.conf with the entry Code:
dev.rtc.max-user-freq = 1024
so that hardware timings are set just the way Arpi (or whoever at MPlayer.hq)
thinks they should be set for multimedia playback, and end users can benifit
from using hardware timing. Not to mention removing one more warning a person
may see when running software.
Or the admin could add an 'rtc' group, do a 'chmod g+r /dev/misc/rtc', and
add whoever should have read access to the 'rtc' group ? I am no so sure
if this is an problem that should be handeled inside the ebuild, and anyhow,
most people would not like the sysctl.conf change without supervision ?
Any other ideas/comments/etc ?
I don't think this should be handled in the ebuild silently. Maybe some hint
in the postinst function? Or put it into a "config" function and give a hint
I feel we should have this changed in baselayout.
IE. add a group called rtc, change permissions as neccessary and then advise
in the mplayer postinst to add any regular users wanting to use mplayer should
be added to the rtc group.
I know I would find that group handy for other reasons.
I think instead of creating an rtc group you should utilize current groups. I personally set mine to root:bin 640. I find this to be a much more reasonable permission. People shouldn't have to add everyone that wants to use a video player (and its associated browser plugin) to a certain group.
Also, I think it's worth noting that the window manager if the permissions are not right (at least on my computer w/ metacity).
bug-cleaning. removing security@ cc
Is this still an issue?
If you run >= udev-030, this should be fixed (along with the sysctl.conf change.) The default gentoo permissions for /dev/misc/rtc is 0664 which should make the rtc readable for all users. And the sysctl.conf change allows mplayer to read the rtc at the frequency it wants to.
Thoughts on this? As johnm mentioned, there are probably a number of packages that could utilize such a group. I can think of many video and sound apps myself. I could do it in the MPlayer build, but I'd be more comfortable if it was a base-system created group. Thanks ahead of time for any thoughts.
ntp could also use it i believe
can you give me examples to add to passwd / sysctl.conf ?
/dev/rtc should not be a problem at the moment, as udev has it 664, and I don't think there's someone which needs to be allowed to write to that device.
About max-user-freq, I actually don't know what does that implies, but it's requested by tvtime, also. But this shouldn't be a mplayer bug anymore, it's something for baselayout, imho.
rtc::23: in /etc/group
would probably do. Note that I base the 23 off the fact that I don't see in 23 GID group unless it's something that's part of baselayout and I don't know about.
dev.rtc.max-user-freq = 1024
Should be added to /etc/sysctl.conf someplace.
base-system, please review and close as invalid if you dont like the idea of adding this to the basesystem. thanks
gregkh: what's your opinion ?
Adding another group? Fine with me, send me a patch for the udev rules if you decide to do this.
Actually, I think this change isn't necessare (any more). The MPlayer team now propagates the usleep (or nanosleep?) timing since some benchmarks showed better performance while keeping accuracy.
I'm not sure though if this is already the case for pre8 (which is the oldest MPlayer in portage)..