[Mageia-dev] Problem with gdm metacity again

[JA Magallon]

On Wed, 07 Sep 2011 13:27:05 +0100
Colin Guthrie <mageia at colin.guthr.ie> wrote:

> 'Twas brillig, and JA Magallon at 07/09/11 12:03 did gyre and gimble:
> > On Wed, 7 Sep 2011 13:01:39 +0300
> > Shlomi Fish <shlomif at shlomifish.org> wrote:
> > 
> >> Hi J. A.,
> >>
> >> On Wed, 7 Sep 2011 11:42:33 +0200
> >> JA Magallon <jamagallon at ono.com> wrote:
> >>
> >>> On Wed, 7 Sep 2011 11:15:21 +0200
> >>> JA Magallon <jamagallon at ono.com> wrote:
> >>>
> >>>> Hi...
> >>>>
> >>>> This old problem has surfaced again:
> >>>>
> >>>> .xsession-errors:
> >>>>
> >>>> ...
> >>>> Window manager warning: Screen 0 on display ":0" already has a window manager; try using the --replace option to replace the current window manager.
> >>>> Window manager warning: Screen 0 on display ":0" already has a window manager; try using the --replace option to replace the current window manager.
> >>>> ...
> >>>>
> >>>> I get only the nautilus desktop, with two black bars on top and bottom of the screen.
> >>>> If I launch a terminal, 'gnome-shell --replace' works fine.
> >>>>
> >>
> >> I reported this bug here:
> >>
> >> https://bugs.mageia.org/show_bug.cgi?id=2628
> >>
> >> I can reproduce it here on my x86-64 Mageia Linux Cauldron laptop.
> >>
> >> Regards,
> >>
> >> 	Shlomi Fish
> >>
> >>>> Any idea ?
> >>>> Can it be some personal setting ?
> >>>>
> >>>> TIA
> >>>
> >>> Digging a bit more, something is wrong detecting acceleration.
> >>> In GDM log:
> >>>
> >>> gnome-session[4752]: DEBUG(+): fill: *** Looking if /usr/share/gnome-session/sessions/gdm-shell.session is a valid session file
> >>> gnome-session[4752]: DEBUG(+): fill: *** Launching helper 'bash -c "gnome-shell --help | grep -q gdm-mode && /usr/lib64/gnome-session-check-accelerated"' to know if session is runnable
> >>> gnome-session-is-accelerated: No hardware 3D support.
> >>> gnome-session-check-accelerated: Helper exited with code 256
> >>> gnome-session[4752]: WARNING: Session 'gdm-shell' runnable check failed: Exited with code 1
> >>> gnome-session[4752]: DEBUG(+): fill: *** Session is not runnable
> >>> gnome-session[4752]: DEBUG(+): fill: *** Getting session 'gdm-fallback'
> >>>
> >>> This is for GDM's own session.
> >>> The same happens for user.
> >>>
> >>> Any ideas ? How can I check why this fails ?
> >>> Its a netbook with Intel graphics, so it uses Mesa.
> >>>
> >>> Will check on an nvidia system too.
> >>>
> > 
> > I did, and everything works fine. I even discovered that GDM looks different
> > when acceleration is available ;)).
> > 
> > So these are two separate problems:
> > 
> > - Acceleration detection on some systems, from my limited tests, it works on
> >   nVidia (32bit, will check 64 shortly), and fails on intel (mesa???) graphics.
> >   This can be a bug report for gnome-session (/usr/lib64/gnome-session-check-accelerated*)
> >   or for Mesa if it's it what breaks things.
> > 
> > - In full mode, gnome-shell from the user replaces gnome-shell from gdm.
> >   But in fallback mode, gnome-shell can't replace GDM's metacity.
> 
> It's almost certainly a permissions thing.
> 

Yup, thats the problem.
Booting into systemd gives this:

one:~# ll /dev/dri*
total 0
crw-rw----+ 1 root video 226,  0 2011.09.07 15:12 card0
crw-rw-rw-  1 root video 226, 64 2011.09.07 15:12 controlD64
one:~# getfacl /dev/dri/card0
getfacl: Removing leading '/' from absolute path names
# file: dev/dri/card0
# owner: root
# group: video
user::rw-
user:gdm:rw-
group::rw-
mask::rw-
other::---

But with init, card0 has no acl.

As a quick hack,

one:/dev/dri# service dm stop
Stopping display manager:                                       [  OK  ]
one:/dev/dri# chmod 666 card0
one:/dev/dri# ll
total 0
crw-rw-rw- 1 root video 226,  0 2011.09.07 19:15 card0
crw-rw-rw- 1 root video 226, 64 2011.09.07 19:15 controlD64
one:/dev/dri# service dm start
Starting display manager:                                       [  OK  ]
one:/dev/dri#

made it work!

> I'm not sure GDM registers itself with consolekit anymore. And
> in-so-doing, will not get permissions on the DRI device and thus will
> not be able to run the nice new shell.
> 
> 
> If you run systemd then all should be well.
> 
> Col
> 
> 
>