[MPlayer-dev-eng] [PATCH] adjusting nice level from config/command line

[D Richard Felker III]

On Mon, May 27, 2002 at 07:04:56PM -0400, Brian J. Murrell wrote:
> On Mon, May 27, 2002 at 05:57:26PM -0400, D Richard Felker III wrote:
> > 
> > No, this is impossible -- it will break subsequent vo initialization
> > if the user is using DGA, svgalib, etc.
> 
> I have not looked in detail at the specifics of each of the vo's that
> have this problem so I have to believe that you are right.  I have no
> reason not to.  :-)
> 
> There are a couple of ways to handle this problem though.  One is
> POSIX capabilities (if such devices are protected by capabilities) and
> the other is "pam-console".  The latter sets ownership of devices that
> should only be accessed by the user at the console to his uid
> (keyboard, mouse, video out, cd-rom, etc.).

Neither of these is a valid solution. The device in question is
/dev/mem, which (IMHO) should not even exist, much less ever be
accessible by a nonroot user. If the problem were that simple, it
would already have been fixed. Most people don't even need a
'pam-console' style trick; just putting themselves in a group with
access to the relevant devices suffices. But in this case that is not
an option.

> > There's really no good way to
> > do it. IMO any vo/ao or other feature that needs root is inherently
> > broken and should be fixed/removed so that permissions to open a
> > relevant device node are sufficient.
> 
> Well, the argument could be made that a user at the console of a
> workstation should have ownership and access to the input/output
> hardware of the worksation.

Yes. The kernel should make the hardware accessible through proper
device nodes and drivers. Alas it does not. The kernel sucks. Go
complain to Linus.

(Actually with stuff like fbdev, mga_vid, etc., the hardware IS
accessible through the proper channels. BUT this is not the case for
most users, since their hardware is not supported well or at all
through fbcon. Also, DGA is too stupid to use /dev/fb0 to map the
framebuffer, EVEN IF your X server is configured to control the video
through /dev/fb0! I patched my libdga to fix this, but the XF86
developers don't seem to care to fix it.)

> > Read my earlier post in this thread for an explanation why none of
> > this works.
> 
> Indeed.  I did.  I have not ventured enough to do the pam-console work
> to make this work yet, but I also don't use a "root-needed" vo or ao's
> that my distro does not already bestow the workstation user's
> ownership upon.  I do have a Radeon and I suppose I could use vidix
> with it, but Xvideo seems to work well enough with it.

If your system is madfast it doesn't matter. On the other hand, if
it's barely able to perform well enough to play movies, vidix or
mga_vid is pretty much essential. (Anyone care to make a kernel module
wrapper for the vidix drivers so they don't have to run from
userspace?? I don't have much motivation to do so myself since I use
Matrox.)

Rich