From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2011-August/007573.html | 137 +++++++++++++++++++++++++++++ 1 file changed, 137 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-August/007573.html (limited to 'zarb-ml/mageia-dev/2011-August/007573.html') diff --git a/zarb-ml/mageia-dev/2011-August/007573.html b/zarb-ml/mageia-dev/2011-August/007573.html new file mode 100644 index 000000000..35fbd2e80 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007573.html @@ -0,0 +1,137 @@ + + + + [Mageia-dev] systemd + udev 173 + gnome-shell + + + + + + + + + +

[Mageia-dev] systemd + udev 173 + gnome-shell

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Sat Aug 27 01:46:17 CEST 2011 +

+
+ +
Hi,
+
+OK, so this combo is currently broken!
+
+Here is the explanation.
+
+With udev 172, udev-acl would apply ACLs to devices (such as the DRI
+device) when console-kit registers a new session.
+
+This included the gdm user at the login manager.
+
+systemd is gradually taking over the job of consolekit. This means that
+systemd now handles the ACL writing and login sessions should be
+visiible via systemctl-loginctl (as opposed to ck-list-sessions).
+
+
+With udev 172, both systemd and console-kit would trigger ACL writes.
+Normally this is fine, they both ultimately do the same thing.
+
+But, it seems that in actual fact, systemctl-logind wasn't ever
+registering the gdm session. Thankfully console-kit did, and thus gdm
+user got the ACLs it needed.
+
+
+Now this is where the problem arises. With udev 173, udev-acl knows
+whether or not systemd is running and if it is, it it won't write the
+ACLs. This means that even tho' gdm is still registered with
+console-kit, this will never actually trigger an ACL write.
+
+This means that gdm does not have access to /dev/dri/card0 and thus
+cannot determine if the device is capable of 3D accel. This then sets an
+atom on the root window which the gnome-session-check-accelerated binary
+looks for. This atom acts as a little cache. If it doesn't exist, it
+does a full probe and then writes the atom. The next time it runs it
+finds the atom and skips the actual checks. But as the atom was written
+by gdm when it couldn't access dri, it says no accel is available, even
+although the user can actually access it.
+
+
+I've not yet sussed out gdm is not registering with systemd... it should
+all be automatic via pam... but something somewhere is failing :s
+
+
+Col
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1