Mark Bainter writes:
> I am using devfs (fully) and I'm running into a problem trying to
> get DRI working. I have tried everything I can think of, and no
> matter what when I start X the permissions look like this:
>
> crw-rw---- 1 root root 226, 0 Sep 24 10:25 card0
>
> What's odd is I've had no trouble before this getting devfs
> perms working right. The sound card/etc all work fine. And
> when I run devfsd in trace mode I see this:
>
> Looking for "dri/card0" (0)
> update permissions for "dri/card0" from 20660 to 20666, user.group
> from 0.0 to -1.-1
> Set permission 20666 on "dri/card0"
> Set user.group -1.-1 on "dri/card0"
>
> With a devfsd.conf that looks like:
> LOOKUP mixer MODLOAD
> LOOKUP audio MODLOAD
> LOOKUP dsp MODLOAD
> REGISTER mixer PERMISSIONS -1.-1 666
> REGISTER dsp PERMISSIONS -1.-1 666
> REGISTER agpgart PERMISSIONS -1.-1 666
> REGISTER dri/.* PERMISSIONS -1.-1 666
>
> agpgart works fine. As does mixer and dsp.
> And if I restart devfsd after starting X the permissions get
> set right on dri/card0 too. But of course, at that time it's
> too late.
>
> In case I was missing an event somewhere, I've gone through and
> tried each of the other events I thought relevent (lookup,
> create, and change) The first two had no effect, the third
> (obv) created a lot of load on my system but didn't help really.
> I also tried combinations of them together, which also didn't work.
It might be that X is changing the permissions of the device, and that
this isn't a devfs problem at all! Something you can do to catch X in
the act is to kill your existing devfsd and run it thus:
# devfsd /dev -d
This will show the devfs->devfsd events, without devfsd doing any
other processing. Then start X and see if there is a change event.
If so, it shows that X has stuck in it's grubby hands.
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|