ubuntu-multiseat team mailing list archive

[Schlomo Schapiro <schlomo@xxxxxxxxxxxx>]

Hi,

I did some further testing.

​Now I would say that the core problem is that one cannot start more than
one X server on secondary seats. The X server fails to start with a
DRM-related error like this:

​[  1716.627] (EE) intel(0): [drm] failed to set drm interface version:
Permission denied [13].
[  1716.627] (EE) intel(0): Failed to claim DRM device.
[  1716.627] (II) UnloadModule: "intel"
[  1716.627] (EE) Screen(s) found, but none have a usable configuration.

​The kernel log shows nothing related.

All other effects would be IMHO results of this problem. A simple test
consists of starting another X server with the same command line options
(except the DISPLAY) as started by the display manager.

I tried various combinations between Intel chipset graphics, NVidia and AMD
graphics cards. No matter which of those I put as primary, the secondary
always shows this problem.

I also tried the same on vivid and even on Fedora 21 which both have more
recent software version but exhibit the same problem.

In conclusion I would say that both lightdm and light-locker do the right
thing.

Do you have any advice about how to work on this DRM problem or at least
where to report it?

I also tried Ubuntu instead of Xubuntu and was surprised to find out that
Ubuntu works much better for my scenario. Unity locks sessions from within
and also shows a password dialog thereby supporting secondary seats much
better than Xubuntu with light-locker.

Unity also does not offer to switch to other users on the secondary screen,
which again fits me better.​


On 1 January 2015 at 03:07, Richard Hansen <ubuntu-a7x@xxxxxxxxxxxxxxx>
wrote:

> On 12/31/2014 08:13 PM, Schlomo Schapiro wrote:
> > Hi,
> >
> > see https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1406834
>
> Looks like you have two problems that I'm guessing are unrelated:
>
>   * Scenario #1:  When using xscreensaver, locking works but LightDM
>     keeps trying and failing to spawn a greeter on non-seat0 seats
>     while the screen is in power-save mode.
>   * Scenario #2:  When using light-locker, locking on non-seat0 seats
>     doesn't properly session-switch to LightDM.
>
> You filed a bug report for scenario #1; would you please also file a bug
> report for scenario #2 (against light-locker)?
>

​AFAIKT light-locker works fine provided one can start another X server. In
light of the current state of that I would say that the design decision of
light-locker was correct but premature.

> On 1 January 2015 at 01:34, Richard Hansen <ubuntu-a7x@xxxxxxxxxxxxxxx>
> > wrote:
> >>
> >> Support for session switching on non-seat0 seats was added in systemd
> >> 208 [1] and xorg-server 1.16 [2], both of which are available in utopic
> >> (but not trusty).
> >>
> >> [1]
> http://cgit.freedesktop.org/systemd/systemd/commit/?id=d7bd01b547bd91353513131561de9cc7d9f7d405
> >> [2]
> http://cgit.freedesktop.org/xorg/xserver/commit/?id=cac39219898f5e5a59ff8d8d6524f5fe0d111469
> >
> > ​Very very cool. So now I found out that it does not work for me.
>
> I should mention that I have never tried utopic (I'm still running
> trusty) so I don't know if session switching on non-seat0 seats would
> work for me either.
>
> > The question is why. I guess I'll try also with different graphics cards
> > to find out if it is related to the radeon driver.
>
> By "radeon driver" I assume you mean the open source radeon driver and
> not the proprietary fglrx driver, right?
>

​Yes, at least with the proprietary NVidia driver second seats seem
impossible. My card is too old to be supported by the fglrx driver.
​


>
> >>> It seems to me rather that light-locker just locks the session with the
> >>> "This session is locked" but then lightdm cannot show the greeter
> >>> anywhere to ask for a passwort to unlock it.
> >>
> >> Yes; seems like something is trying to switch sessions but failing
> >> somehow.  Anything interesting in lightdm or X logs?
> >
> > ​Yes, see above bug report. lightdm.log is now 1.4 GB after just a few
> > hours...
>
> What about scenario #2 (using light-locker)?
>
> >>> and that after logging out
> >>> of the session there is no new login screen. Apparently lightdm does
> not
> >>> start a new session on this seat after the first session is done.
> >>
> >> That seems odd to me, and sounds like a lightdm bug...  Do the lightdm
> >> logs show anything interesting?
> >
> > ​Yes, it fails to start another X server. I guess that in my case (using
> > xscreensaver instead of light-locker), I would expect this not to happen
> > unless it is doing it in order to offer another login for user switching.
>
> Whenever you log out, the X server is supposed to exit -- that's normal
> behavior.  The display manager (LightDM) is then supposed to spawn a new
> X instance.
>
> What happens when you set allow-user-switching=false, switch to
> light-locker, log in to seat-1, then log out?  Does it still fail?  What
> are the symptoms exactly?  Anything interesting in the logs?
>

​I think that maybe here is an issue with lightdm as in that case the logs
would just say that the session finished and nothing more. Is there a real
debug mode for lightdm that reveals the internal decision processes?
​


>
> >> But it should, given that utopic should support session switching on
> >> non-seat0 seats.  I would expect trusty to have problems, but not
> utopic.
> >
> > ​I see. Against which package(s) should I report this as a bug?
>
> light-locker
>
> > Is this an "official" feature of utopic?
>
> I don't know if any Ubuntu release has any "official" features, but
> certainly there are some features Canonical cares more about than
> others.  I don't think multiseat is high on their list of priorities.
>

​Sad indeed. It is such a cool feature and starts to work really well now.
​


>
> However, session switching on non-seat0 seats is a feature of logind
> v208 and X server v1.16, and those are in utopic, so if it's not working
> then it's a bug in utopic that should be addressed.  And it will be
> addressed if there's enough manpower to troubleshoot, fix, and test
> (which is where volunteers like us come in).
>

​See above, seems to be not related to light* but to X and maybe systemd. A
hint against which packages to report would help me and I would gladly
report that.

Kind Regards,
Schlomo