[MPlayer-users] Is this the beginning of the naming blues?

[Alejandro Nova]

Hi everyone.

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.

Thanks.

Alejandro Nova.