<p dir="ltr">On Sep 30, 2015 17:26, "Andreas Beckmann" <<a href="mailto:anbe@debian.org">anbe@debian.org</a>> wrote:<br>
><br>
> On 2015-09-29 10:31, Luca Boccassi wrote:<br>
> > Another solution would be having the DM packages themselves add their users<br>
> > to the video group on install as well, but I'd be wary of adding<br>
> > workarounds in other packages, especially when it involves extending<br>
> > privileges, and I suspect the respective mainteiners feel the same way.<br>
> ><br>
> > Andreas, Vincent, what are your thoughts on this?<br>
><br>
> I don't have time to dig into this right now. IIRC some consolekit magic<br>
> puts the local X user into to the video group, so GL works for the<br>
> logged in user... but not for most *dm.<br>
><br>
> Did someone check whether this behavior depends on systemd vs. sysvinit?<br>
><br>
> Do the device permissions differ dependening on the way the nvidia<br>
> module was loaded?</p>
<p dir="ltr">Ran a few tests, with glx-alternatives 0.6 and 340.93-2, and without gdm in video group:</p>
<p dir="ltr">old modprobe, sysvinit: gdm works!<br>
old modprobe, systemd: gdm oops</p>
<p dir="ltr">new modprobe, systemd: gdm oops<br>
new modprobe, sysvinit: gdm oops</p>
<p dir="ltr">The first result is interesting I think, I'd expected it to work.</p>
<p dir="ltr">> We should get the maintainers of the affected *dm packages involved in<br>
> this discussion.</p>
<p dir="ltr">There's a bug open against gdm, cc'ed.</p>
<p dir="ltr">Kind regards,<br>
Luca Boccassi</p>