[MPlayer-users] Is this the beginning of the naming blues?
novaasc at vtr.net
Sat Jul 24 08:25:53 CEST 2004
I have a system configured with Slackware 10, udev, and kernel 2.6.7
(the latest stable kernel). All began with my switching from kernel
2.4.26 (AudioSlack patched) to kernel 2.6.7. MPlayer was playing fine,
and everything went OK.
When a Slackware 10 user upgrades his kernel to 2.6 series, Slackware
detects that, and enables udev by default (it is soooo beautiful...).
Later, I compiled a monolithic kernel with SELinux enabled and
realtime-lsm securtity module (for giving JACK its realtime
capabilites). and trouble began. With tdfxfb enabled, I could not play
anything with this driver in MPlayer. The message printed was:
tdfxfb: Couldn't map memory areas. Invalid argument.
Ok, I thought. Let's try with another driver. Let's say, for instance,
sdl. And another surprise came after. As root and in the command line, I
was receiving the message:
Failed to open /dev/rtc. Device or resource busy (it should be readable
by the user)
Using usleep() timing.
Marvelous. I'm losing my fine timing, but, what is worse, I was using
CPU time for things that MPlayer can do without using it. I thought the
message was udev related, because udev was configured to create the RTC
link in /dev/misc/rtc, not /dev/rtc. So I configured udev.rules to
create RTC into /dev/rtc and RTC worked again. (I needed to kill
manually some zombie MPlayers who were rendering the RTC busy, but it
worked, I discovered that through a ps ax | grep "mp")
What I'm thinking is, MPlayer is not following the new naming scheme
introduced in kernel 2.6.6. It is looking for RTC in /dev/rtc, and when
it founds a symlink, it says that the resource is busy instead of follow
the symlink. And, what about the tdfxfb error? I haven't tried yet
because I fear to destroy my framebuffer setup, but I think that it's
the same bug: my framebuffer device is not /dev/fb0, it's /dev/fb/0 with
a symlink pointing to /dev/fb0.
I don't know what am I doing wrong. I know that the info here is too few
to file a bug report, and that's because I don't know if I am
misconfiguring my system, if it's a tdfxfb kernel module bug (that is
really possible, the kernel developers don't know that someone else
patched the tdfxfb module against 2.4.3 and raised the version number to
2.4) or if it's really an MPlayer bug. If a developer needs more info,
I'll collect that info and send it to him ASAP.
More information about the MPlayer-users