On Tue, 2015-10-20 at 11:56 +0200, Miguel Angel Rojas wrote: > > I must first say that I am absolutely not familiar with KDE, > the QT > environment and how it works. But the thread that raises the > abort > doesn't look like it's in the GL libraries code: > > Maybe there's some context I'm missing. Forgive me for asking, > but are > you sure this is due to the Nvidia driver packages or > glx-alternatives? > > > > Hi Luca, > > > But indeed, it is! I conducted the same experiments as Vladimir did > with the same result. Something is wrong with the glx beyond 0.6.x > (bad packaging, new API, new behavior? I don't know). I would > recommend to reproduce as it is very easy to do it and you will see > what we are talking about.
Hi Miguel, The reason I'm asking is because I can't reproduce any problems on GDM, with any software that uses GLX or other libraries, after adding the workaround. But I noticed something looking again at the system info you forwarded, the only user in the "video" group is sddm: video:x:44:sddm I verified yesterday that even on GDM both the DM-manager user (in my case Debian-gdm) AND my user MUST be in the video group, otherwise the problem occurs. Could you please try to add your user to the video group and see if that helps? > Talking about Bug #799948, is there a reason why sddm user should be > included in video? (because it seems to be the workaround) If so, > someone should notify sddm guys that is somehow required due to new > upstream requirement in nvidia glx packages. We don't have a clear > explanation about it. We are still discussing and investigating that. It is not a new upstream requirement but a fix to the device nodes permissions that we are trying out, but it seems to be causing way too much grief. Please see this message by Andreas [1] for more details about the background. Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part