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/007588.html | 131 +++++++++++++++++++++++++++++ 1 file changed, 131 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-August/007588.html (limited to 'zarb-ml/mageia-dev/2011-August/007588.html') diff --git a/zarb-ml/mageia-dev/2011-August/007588.html b/zarb-ml/mageia-dev/2011-August/007588.html new file mode 100644 index 000000000..977d7319b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007588.html @@ -0,0 +1,131 @@ + + + + [Mageia-dev] systemd + udev 173 + gnome-shell + + + + + + + + + +

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

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

+
+ +
'Twas brillig, and Colin Guthrie at 27/08/11 00:46 did gyre and gimble:
+> 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
+
+OK, sussed it out eventually (I was looking in fedora's "master" branch
+rather than "f16" branch so missed some patches :()
+
+gdm patched to make it all work now. I'm not really sure how kdm will
+behave but I wouldn't be surprised if it's broken.
+
+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