[systemd-devel] Possible regression/ABI breakage in Xorg socket-activation support
Hi there! Regarging https://bugs.freedesktop.org/show_bug.cgi?id=93072, I've also observed this issue in Ubuntu 15.10 (xorg-server 1.17.2 and systemd 225) and 16.04 alpha 2 (xorg-server 1.17.3 and systemd 229), but not in openSUSE Leap 42.1 (xorg-server 1.17.2 and systemd 210). Could it be a Xorg regression? A systemd regression? Or some kind of libsystemd ABI breakage? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Some questions regarding seat preperty CanGraphical
I'm contributing with some DM projects (LightDM, SDDM) in order to provide full systemd-logind multi-seat support. IMHO the most challenging part is monitoring seat's property CanGraphical an reacting properly when this property changes. If I understand systemd-logind code correctly, a seat will only have CanGraphical=yes if it has a master device (which used to be the graphics device if it uses KMS drivers), right? If so, than this property is only relevant for seat0, because other seats doesn't exist at all if they don't have a master device, right? Since system release 198, we can tag any suitable device as a seat master device, so shouldn't it be more clear if this property was renamed to e.g. HasMasterDevice? Or introduce another check to ensure a seat can really handle a graphical display? I imagine this property was introduced for the case where system boots so fast that a given DM service is started before seat0 master (graphics) device is ready. However, if seat0 graphics device doesn't have KMS drivers (e.g. a VirtualBox guest without Guest Additions installed), then seat0 will never get CanGraphical=yes. That said, how do you suggest this to be handled by DM? It seems GDM currently doesn't support it, and LightDM was forced to make this support optional and disabled by default (after some VirtualBox guests without Guest Additions failed to boot to graphical display). SDDM implementation is currently in progress, and there may be some discussion whether CanGraphical monitoring should be supported or not. The last (but not least): is this property really needed? I mean, do you have any use case where a DM was started before main graphics device is ready? -- *Laércio de Sousa* *Orientador de Informática* *Escola Municipal "Professor Eulálio Gruppi"* *Rua Ismael da Silva Mello, 559, Mogi Moderno* *Mogi das Cruzes - SPCEP 08717-390* Telefone: (11) 4726-8313 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd and hostname supplied by DHCP
Some guys set the following config in /etc/polkit-1/rules.d:
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.hostname1.set-hostname" &&
subject.user == "systemd-network") {
return polkit.Result.YES;
}
});
Alternatively, I use the following config in
/etc/polkit/localauthority/50-local.d of my Debian Jessie installation (I
failed to make it apply polkit rules):
[Allow systemd-networkd to set transient hostname from DHCP]
Identity=unix-user:systemd-network
Action=org.freedesktop.hostname1.set-hostname
ResultAny=yes
ResultInactive=yes
ResultActive=yes
Good luck!
2015-10-02 9:00 GMT-03:00 Alessio Igor Bogani <alessioigorbog...@gmail.com>:
> Hi,
>
> On 29 September 2015 at 13:53, Alessio Igor Bogani
> <alessioigorbog...@gmail.com> wrote:
> > Hi David,
> >
> > On 28 September 2015 at 16:05, David Timothy Strauss
> > <da...@davidstrauss.net> wrote:
> >> On Mon, Sep 28, 2015 at 1:19 AM Alessio Igor Bogani
> >> <alessioigorbog...@gmail.com> wrote:
> > [...]
> >>> The systemd 219 brought with Yocto "Fido" can't set hostname supplied
> >>> by DHCP on my Beaglebone:
> > [...]
> >> "Could not set hostname: No route to host" sounds like systemd is
> trying to
> >> resolve and ping the provided hostname. But, it's failing, and so
> systemd is
> >> deciding that it's not a usable hostname. Doesn't seem related to the
> DHCP
> >> protocol implementation at all.
>
> If I enable debug:
> Oct 02 08:10:43 localhost systemd-networkd[277]: Got message
> type=error sender=:1.4 destination=:1.2 object=n/a interface=n/a
> member=n/a cookie=5 reply_cookie=12 error=The name
> org.freedesktop.PolicyKit1 was not provided by any .service files
> Oct 02 08:10:43 localhost systemd-networkd[277]: eth0: Could not set
> hostname: No route to host
>
> Evidently Yocto builds systemd enabling polkit without provides it. So
> I added it and an additional polkit's rule
> (https://bugs.freedesktop.org/show_bug.cgi?id=81626) and my Beaglebone
> retrieve and set host-name correctly.
>
> I would prefer avoid PolicyKit. Moreover in the systemd 219's README
> PolicyKit is stated as optional (line 141). So I have rebuild systemd
> disabling policykit explicitly and it doesn't work:
>
> Oct 02 13:35:10 localhost systemd-networkd[235]: Got message
> type=error sender=:1.4 destination=:1.2 object=n/a interface=n/a
> member=n/a cookie=4 reply_cookie=12 error=Permission denied
> Oct 02 13:35:10 localhost systemd-networkd[235]: eth0:
> Could not set hostname: Permission denied
>
> Do you have any tips?
>
> Thank in advance!
>
> Ciao,
> Alessio
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
--
*Laércio de Sousa*
*Orientador de Informática*
*Escola Municipal "Professor Eulálio Gruppi"*
*Rua Ismael da Silva Mello, 559, Mogi Moderno*
*Mogi das Cruzes - SPCEP 08717-390*
Telefone: (11) 4726-8313
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] "StopWhenUnneeded"-like option for socket-activated services?
Hi there! I have a curiosity: is there some way to systemd to detect when all connections to a given socket are closed, so that the service assigned to that socket unit can be automatically stopped (but the socket unit itself keeps listening)? Something similar to StopWhenUnneeded option, which makes a service stop automatically when its dependants have stopped. My practical example: I'm trying new possibilities with my single-GPU multi-seat setup (a bare Xorg server spanning all video outputs, on top of which a Xephyr instance is started for each output/seat). My current system starts a socket-activated systemd service for the bare Xorg when my LightDM starts its first Xephyr instance. I would like to stop the bare Xorg service when all Xephyr-based seats are removed (e.g. their master devices are unplugged or LightDM service is stopped). Thanks in advance! -- *Laércio de Sousa* *Orientador de Informática* *Escola Municipal "Professor Eulálio Gruppi"* *Rua Ismael da Silva Mello, 559, Mogi Moderno* *Mogi das Cruzes - SPCEP 08717-390* Telefone: (11) 4726-8313 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Multi seats setup How-to
TH=platform-evdi.1
> E: ID_PATH_TAG=platform-evdi_1
> E: ID_SEAT=seat1
> E: MAJOR=226
> E: MINOR=2
> E: SUBSYSTEM=drm
> E: TAGS=:seat:seat1:uaccess:
> E: USEC_INITIALIZED=160111782
>
>
> $ cat /etc/udev/rules.d/99-displaylink.rules
> (shipped with the displaylink .rmp driver)
> ---
> ACTION=="add", SUBSYSTEM=="usb", ENV{ID_VENDOR}=="DisplayLink",
> MODE="0660", RUN+="/bin/systemctl start displaylink.service"
> ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_VENDOR}=="DisplayLink",
> RUN+="/bin/systemctl stop displaylink.service"
> --
>
> $ cat /etc/udev/rules.d/99-nvidia_seats.rules
> --
> # provide a suitable udev rule to tag your NVIDIA card as "master-of-seat"
> SUBSYSTEM=="drm", KERNEL=="card[0-9]*", ATTRS{vendor}=="0x10de",
> DRIVERS=="nvidia", TAG+="master-of-seat"
>
> SUBSYSTEM=="pci", ATTRS{vendor}=="0x10de", DRIVER=="nvidia",
> TAG+="seat", TAG+="master-of-seat"
>
>
> cat /etc/udev/rules.d/72-seat-drm-platform-evdi_1.rules
> ---
> TAG=="seat", ENV{ID_FOR_SEAT}=="drm-platform-evdi_1", ENV{ID_SEAT}="seat1"
> -
>
> cat /etc/udev/rules.d/72-seat-input-pci-_00_14_0-usb-0_10_4_1_1_1.rules
> --
>
> TAG=="seat", ENV{ID_FOR_SEAT}=="input-pci-_00_14_0-usb-0_10_4_1_1_1",
> ENV{ID_SEAT}="seat1"
> ---
>
>
>
> # systemctl restart systemd-udev-trigger.service (or even reboot)
>
> $ loginctl show-session (two users logged in)
> SESSIONUID USER SEAT
> 2 1001 Martin seat0
> 1 1000 Louisseat0
> c1 42 gdm seat0
> 3 sessions listed.
>
> $ loginctl list-seats
>
> SEAT
> seat0
>
> 1 seats listed.
>
> xx
>
> What am I missing? Why can't I create seat1 ?
> Maybe # rm /etc/udev/rules.d/72* and try again ?
>
>
>
>
> Thank you for help.
>
>
> >
> > Will try this later when I will get hand on the Fedora box.
> > Thank you so much for your clarifications.
> >
> > success,
> >
> > floris
> > ___
> > systemd-devel mailing list
> > systemd-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> >
> >
>
>
>
> --
>
> google.com/+arnaudgabourygabx
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
--
*Laércio de Sousa*
*Orientador de Informática*
*Escola Municipal "Professor Eulálio Gruppi"*
*Rua Ismael da Silva Mello, 559, Mogi Moderno*
*Mogi das Cruzes - SPCEP 08717-390*
Telefone: (11) 4726-8313
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] help : loginctl won't add new seat
Hi Benoit! I guess you forgot to tag your seat1 card as "master-of-seat". 2015-09-02 6:52 GMT-03:00 Benoit Barthelet <benoit.barthe...@gmail.com>: > long story short I had a working multiseat setup with 2 GPU / 2 mices > and 2 keyboards > > I changed GPU drivers from open-source radeon to fglrx and it stopped > working > > before the driver change I had configured the 2nd seat to used the gpu > / mice / keys with : > > loginctl attach seat1 > /sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/ > etc.. > > the issue with the new drivers it seems is that I can't find the card0 > in the /sys hierarchy, > > for instance, it seems to be one of my card, but no seat tag : > udevadm info --query=all > --path=/sys/devices/pci:00/:00:07.0/:03:00.0 > > P: /devices/pci:00/:00:07.0/:03:00.0 > E: DEVPATH=/devices/pci:00/:00:07.0/:03:00.0 > E: DRIVER=fglrx_pci > E: ID_MODEL_FROM_DATABASE=Tahiti PRO [Radeon HD 7950/8950 OEM / R9 280] > E: ID_PCI_CLASS_FROM_DATABASE=Display controller > E: ID_PCI_INTERFACE_FROM_DATABASE=VGA controller > E: ID_PCI_SUBCLASS_FROM_DATABASE=VGA compatible controller > E: ID_VENDOR_FROM_DATABASE=Advanced Micro Devices, Inc. [AMD/ATI] > E: MODALIAS=pci:v1002d679Asv174BsdE207bc03sc00i00 > E: PCI_CLASS=3 > E: PCI_ID=1002:679A > E: PCI_SLOT_NAME=:03:00.0 > E: PCI_SUBSYS_ID=174B:E207 > E: SUBSYSTEM=pci > E: USEC_INITIALIZED=4263516 > > So I tried to create manually a udev rule > > /etc/udev/rules.d/71-ati.rules > > SUBSYSTEM=="pci", > DEVPATH=="/devices/pci:00/:00:01.0/:01:00.0", TAG+="seat", > TAG+="master-of-seat" > SUBSYSTEM=="pci", > DEVPATH=="/devices/pci:00/:00:07.0/:03:00.0", TAG+="seat", > TAG+="seat1" > > and now loginctl seat-status seat0 gives a master tag after udevadm > trigger : > ├─/sys/devices/pci:00/:00:01.0/:01:00.0 > │ [MASTER] pci::01:00.0 > > but I can never have a seat1, it never appears so the display manager > never tries to launch 2nd X session ) > > I'm at a loss here. any help appreciated > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- *Laércio de Sousa* *Orientador de Informática* *Escola Municipal "Professor Eulálio Gruppi"* *Rua Ismael da Silva Mello, 559, Mogi Moderno* *Mogi das Cruzes - SPCEP 08717-390* Telefone: (11) 4726-8313 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Multi seats
Hi Arnaud!
I've been researching systemd-based multi-seat setups with non-KMS video
drivers for a couple of years.
In principle, yes, you can set up a multi-seat system with proprietary
NVIDIA drivers, provided you:
* provide a suitable udev rule to tag your NVIDIA card as master-of-seat
(they are tagged by default if using Nouveau drivers). Examples:
SUBSYSTEM==drm, KERNEL==card[0-9]*, ATTRS{vendor}==0x10de, DRIVERS
==nvidia, TAG+=master-of-seat
SUBSYSTEM==pci, ATTRS{vendor}==0x10de, DRIVER==nvidia, TAG+=seat
, TAG+=master-of-seat
* Have xorg-server 1.16 or newer installed
* Provide a suitable xorg.conf for your NVIDIA card, not forgetting to put
MatchSeat entries in Device/Screen/ServerLayout sections.
* Have LightDM 1.12 or newer installed (if you don't use GNOME)
Att.
2015-08-28 7:58 GMT-03:00 arnaud gaboury arnaud.gabo...@gmail.com:
One year ago, I tried to setup multi seats, see this thread[0]. By
that time, I gave up as my configuration was not made for such a
fetaure.
Now I am back with all the needed tools to do it easily (I think so):
- Fedora 22
- lightdm GDM
- an USB 3 plugable dockin station
As good how-to on this topic are few, I wonder a few things:
- is the proprietary Nvidia driver Ok or shall I indeed use Nouveau
(my card is Nvidia one)?
- are the lightdm/Xorg setup configuring accordingly or shall I edit
manually the conf files?
I understand the whole principle to $ loginctl attach seatNumber
/device/apth.
Thank you for a few hints.
[0]
http://lists.freedesktop.org/archives/systemd-devel/2014-August/022403.html
--
google.com/+arnaudgabourygabx
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
*Laércio de Sousa*
*Orientador de Informática*
*Escola Municipal Professor Eulálio Gruppi*
*Rua Ismael da Silva Mello, 559, Mogi Moderno*
*Mogi das Cruzes - SPCEP 08717-390*
Telefone: (11) 4726-8313
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Multi seats
You're right. If you use GNOME, GDM is ready for you. In any other case,
use LightDM = 1.12. Automatic multi-seat support for SDDM (used by KDE and
LXQt) is still WIP.
2015-08-28 8:42 GMT-03:00 arnaud gaboury arnaud.gabo...@gmail.com:
On Fri, Aug 28, 2015 at 1:37 PM, Laércio de Sousa
laercioso...@sme-mogidascruzes.sp.gov.br wrote:
Hi Arnaud!
I've been researching systemd-based multi-seat setups with non-KMS video
drivers for a couple of years.
In principle, yes, you can set up a multi-seat system with proprietary
NVIDIA drivers, provided you:
* provide a suitable udev rule to tag your NVIDIA card as
master-of-seat
(they are tagged by default if using Nouveau drivers). Examples:
SUBSYSTEM==drm, KERNEL==card[0-9]*, ATTRS{vendor}==0x10de,
DRIVERS==nvidia, TAG+=master-of-seat
SUBSYSTEM==pci, ATTRS{vendor}==0x10de, DRIVER==nvidia,
TAG+=seat, TAG+=master-of-seat
* Have xorg-server 1.16 or newer installed
* Provide a suitable xorg.conf for your NVIDIA card, not forgetting to
put
MatchSeat entries in Device/Screen/ServerLayout sections.
* Have LightDM 1.12 or newer installed (if you don't use GNOME)
In fact I was wrong in my presentation. Login window is now managed by
GDM in Fedora 22, not Lightdm. I guess I do not need to install and
log with Lightdm, am I right?
Att.
2015-08-28 7:58 GMT-03:00 arnaud gaboury arnaud.gabo...@gmail.com:
One year ago, I tried to setup multi seats, see this thread[0]. By
that time, I gave up as my configuration was not made for such a
fetaure.
Now I am back with all the needed tools to do it easily (I think so):
- Fedora 22
- lightdm GDM
- an USB 3 plugable dockin station
As good how-to on this topic are few, I wonder a few things:
- is the proprietary Nvidia driver Ok or shall I indeed use Nouveau
(my card is Nvidia one)?
- are the lightdm/Xorg setup configuring accordingly or shall I edit
manually the conf files?
I understand the whole principle to $ loginctl attach seatNumber
/device/apth.
Thank you for a few hints.
[0]
http://lists.freedesktop.org/archives/systemd-devel/2014-August/022403.html
--
google.com/+arnaudgabourygabx
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Laércio de Sousa
Orientador de Informática
Escola Municipal Professor Eulálio Gruppi
Rua Ismael da Silva Mello, 559, Mogi Moderno
Mogi das Cruzes - SP
CEP 08717-390
Telefone: (11) 4726-8313
--
google.com/+arnaudgabourygabx
--
*Laércio de Sousa*
*Orientador de Informática*
*Escola Municipal Professor Eulálio Gruppi*
*Rua Ismael da Silva Mello, 559, Mogi Moderno*
*Mogi das Cruzes - SPCEP 08717-390*
Telefone: (11) 4726-8313
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sd 221 regression: login - nonexistent sessions via lightdm
I can confirm lightdm greeter leaves some proccesses behind when it's
closed (like dbus-launch, dbus-daemon, at-spi-bus-launcher...) They are
only definitely terminated when user logs out from that seat.
2015-07-07 14:10 GMT-03:00 David Herrmann dh.herrm...@gmail.com:
Hi
On Tue, Jul 7, 2015 at 6:55 PM, Martin Pitt martin.p...@ubuntu.com
wrote:
Hey David,
David Herrmann [2015-07-07 18:31 +0200]:
Revert login: re-use VT-sessions if they already exist - commit
0204c4b
http://cgit.freedesktop.org/systemd/systemd/commit/?id=0204c4b
Can someone elaborate what exactly lightdm does here? We really want
to prevent multiple sessions on the same VT. This is just nasty and
never made any sense. So I'm really interested why lightdm doesn't
kill it's manager-session before it starts the new session. Any
particular reason here?
I'll let Robert answer with the details, but something I noticed:
It's not that simple to reproduce, but sometimes it seems the lightdm
greeter session (running as user lightdm, where you select user/type
password and so on) doesn't completely terminate, but some processes
stay around in it. Thus the greeter session stays around in state
Closing, and then the real session starts on the same VT.
I asked the reporter of https://launchpad.net/bugs/1472259 to attach
systemd-cgls, so that we can see what's running in the session.
So it might indeed just be a race in lightdm. Hmm..
Anyway, this patch here should also fix the issue (if it does, I'll
commit something proper).
Thanks
David
diff --git a/src/login/logind-dbus.c b/src/login/logind-dbus.c
index 0cc2cdf..bced693 100644
--- a/src/login/logind-dbus.c
+++ b/src/login/logind-dbus.c
@@ -690,8 +690,11 @@ static int method_create_session
}
manager_get_session_by_pid(m, leader, session);
-if (!session vtnr 0 vtnr m-seat0-position_count)
+if (!session vtnr 0 vtnr m-seat0-position_count) {
session = m-seat0-positions[vtnr];
+if (session session-class == SESSION_GREETER)
+session = NULL;
+}
if (session) {
_cleanup_free_ char *path = NULL;
_cleanup_close_ int fifo_fd = -1;
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
*Laércio de Sousa*
*Orientador de Informática*
*Escola Municipal Professor Eulálio Gruppi*
*Rua Ismael da Silva Mello, 559, Mogi Moderno*
*Mogi das Cruzes - SPCEP 08717-390*
Telefone: (11) 4726-8313
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [OFF-TOPIC] What's the current status of DRM/KMS device node splitting and single-GPU multiseat support?
Hi there! Some time ago I've read in David Herrmann's blog about DRM/KMS device node splitting project, and now I realised that render node splitting is already merged into kernel and enabled by default since release 3.17, which is going to be included in major distros' next releases. I suppose it's still not sufficient to have finally several Xorg servers running on different outputs of a same graphics card (needed for full single-GPU multiseat), right? What's still lacking? Thanks in advance! -- *Laércio de Sousa* *Orientador de Informática* *Escola Municipal Professor Eulálio Gruppi* *Rua Ismael da Silva Mello, 559, Mogi Moderno* *Mogi das Cruzes - SPCEP 08717-390* Telefone: (11) 4726-8313 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Should systemd-logind provide a DM-independent mechanism for handling guest accounts?
2014-11-11 20:56 GMT-02:00 Daniel J Walsh dwa...@redhat.com: The problems would be in having multiple users get access to the machine at the same time. For this you need something that generates a UID on the fly for the user. I would expect a fairly simple pam module could be done for this. One problem with this though would be a user might log in as guest user but endup getting the guest134 user account. This means you would want some kind of sssd interaction, so a user executing id or ls -lZ ~/ Would see all of his files and processes running as guest. This is more or less what LightDM currently does in its built-in guest account support. There's no user 'guest' previously created. Instead, login as guest is a special entry in LightDM. Whenever a user logs in as guest, a new temporary user is added with username 'guest-XX' (with XX replaced with a random character sequence) and GECOS Guest, and a temporary home folder is created. When guest user logs out, this temporary user is deleted along with its home folder. With this implementation, LightDM on-the-fly guest accounts are completely multi-seat compliant. The downside is that normal and guest users need to be treated differently in lightdm.conf. For example, there are distinct options for autologin as normal user and autologin as guest. -- *Laércio de Sousa* *Orientador de Informática* *Escola Municipal Professor Eulálio Gruppi* *Rua Ismael da Silva Mello, 559, Mogi Moderno* *Mogi das Cruzes - SPCEP 08717-390* Telefone: (11) 4726-8313 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Should systemd-logind provide a DM-independent mechanism for handling guest accounts?
Hi there! Currently there are few alternatives for implementing guest accounts in Linux systems. I know only two: an AppArmor-based approach implemented in LightDM, and a SELinux-based approach implemented in Fedora's package xguest that works with GDM. There's no option for console guest login (should it be needed?). I was thinking if systemd-logind could handle itself guest accounts in the future, making it available for use by any display manager (and even console logins, who knows?). What do you think about it? -- *Laércio de Sousa* *Orientador de Informática* *Escola Municipal Professor Eulálio Gruppi* *Rua Ismael da Silva Mello, 559, Mogi Moderno* *Mogi das Cruzes - SPCEP 08717-390* Telefone: (11) 4726-8313 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Tagging NVIDIA graphics devices (with proprietary drivers) as master-of-seat
Hi there!
For anyone interested in tagging NVIDIA graphics devices with proprietary
drivers as master-of-seat for use with logind, I suggest the following
udev rule:
SUBSYSTEM==drm, KERNEL==card[0-9]*, ATTRS{vendor}==0x10de,
DRIVERS==nvidia, TAG+=master-of-seat
If no /dev/dri/card* kernel devices are available in the system (e.g. if
linux drm module is not loaded), the following alternative works, too:
SUBSYSTEM==pci, ATTRS{vendor}==0x10de, DRIVER==nvidia, TAG+=seat,
TAG+=master-of-seat
NOTE: These rules can be adapted for AMD proprietary drivers. Just replace
0x10de with 0x1002 and nvidia with fglrx.
I don't know if there's any upstream interest in shipping these rules with
systemd (I guess not), but at least one downstream (Ubuntu) already ships
them (with NVIDIA/AMD driver packages). I've already posted these rules in
NVIDIA Developer Forums.
Hope it may be useful.
--
*Laércio de Sousa*
*Orientador de Informática*
*Escola Municipal Professor Eulálio Gruppi*
*Rua Ismael da Silva Mello, 559, Mogi Moderno*
*Mogi das Cruzes - SPCEP 08717-390*
Telefone: (11) 4726-8313
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] login: remove multi-seat-x
Lennart,
I've told you some time ago that Xorg-server since release 1.16 no longer
requires multi-seat-x wrapper.
Em 27/10/2014 11:00, Lennart Poettering lenn...@poettering.net escreveu:
On Sun, 26.10.14 00:30, Timofey Titovets (nefelim...@gmail.com) wrote:
Completed TODO: remove multi-seat-x
Hmm, I don't remember the details of this, did X release a new version
which makes this tool unnecessary? I think they commited code that
made it unnecessary, but did they actually release it?
From 57b2655d2041d2bb2e9b25bef577ead9b27ce6ee Mon Sep 17 00:00:00 2001
From: Timofey Titovets nefelim...@gmail.com
Date: Sun, 26 Oct 2014 00:17:24 +0300
Subject: [PATCH] login: remove multi-seat-x
---
Makefile.am | 14 --
TODO | 2 -
configure.ac | 8
src/login/multi-seat-x.c | 108
---
4 files changed, 132 deletions(-)
delete mode 100644 src/login/multi-seat-x.c
diff --git a/Makefile.am b/Makefile.am
index fae946a..fc86b45 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5400,20 +5400,6 @@ SYSTEM_UNIT_ALIASES += \
BUSNAMES_TARGET_WANTS += \
org.freedesktop.login1.busname
-if ENABLE_MULTI_SEAT_X
-
-systemd_multi_seat_x_SOURCES = \
- src/login/multi-seat-x.c
-
-systemd_multi_seat_x_LDADD = \
- libsystemd-label.la \
- libsystemd-shared.la
-
-rootlibexec_PROGRAMS += \
- systemd-multi-seat-x
-
-endif
-
dist_udevrules_DATA += \
src/login/70-uaccess.rules \
src/login/70-power-switch.rules
diff --git a/TODO b/TODO
index ed00661..195ca55 100644
--- a/TODO
+++ b/TODO
@@ -102,8 +102,6 @@ Features:
* maybe introduce AssertXYZ= similar to ConditionXYZ= that causes a
unit to
fail (instead of skipping it) if some condition is not true...
-* remove multi-seat-x now
-
* refcounting in sd-resolve is borked
* exponential backoff in timesyncd and resolved when we cannot reach a
server
diff --git a/configure.ac b/configure.ac
index c3b4ea3..f69eb82 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1063,14 +1063,6 @@ fi
AM_CONDITIONAL(ENABLE_EFI, [test x$have_efi = xyes])
#
--
-have_multi_seat_x=no
-AC_ARG_ENABLE(multi_seat_x, AS_HELP_STRING([--disable-multi-seat-x], [do
not build multi-seat-x]))
-if test x$enable_multi_seat_x != xno; then
-have_multi_seat_x=yes
-fi
-AM_CONDITIONAL(ENABLE_MULTI_SEAT_X, [test $have_multi_seat_x = yes])
-
-#
--
have_terminal=no
AC_ARG_ENABLE(terminal, AS_HELP_STRING([--enable-terminal], [enable
terminal support]))
if test x$enable_terminal = xyes; then
diff --git a/src/login/multi-seat-x.c b/src/login/multi-seat-x.c
deleted file mode 100644
index 83760d4..000
--- a/src/login/multi-seat-x.c
+++ /dev/null
@@ -1,108 +0,0 @@
-/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
-
-/***
- This file is part of systemd.
-
- Copyright 2011 Lennart Poettering
-
- systemd is free software; you can redistribute it and/or modify it
- under the terms of the GNU Lesser General Public License as published
by
- the Free Software Foundation; either version 2.1 of the License, or
- (at your option) any later version.
-
- systemd is distributed in the hope that it will be useful, but
- WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- Lesser General Public License for more details.
-
- You should have received a copy of the GNU Lesser General Public
License
- along with systemd; If not, see http://www.gnu.org/licenses/.
-***/
-
-#include string.h
-#include unistd.h
-
-#include util.h
-#include mkdir.h
-
-int main(int argc, char *argv[]) {
-
-int i;
-const char *seat = NULL;
-char **new_argv;
-_cleanup_free_ char *path = NULL;
-int r;
-_cleanup_fclose_ FILE *f = NULL;
-
-/* This binary will go away as soon as X natively takes the
- * arguments in question as command line parameters, instead
- * of requiring them in the configuration file. */
-
-/* If this file is removed, don't forget to remove the code
- * that invokes this in gdm and other display managers. */
-
-for (i = 1; i argc; i++)
-if (streq(argv[i], -seat))
-seat = argv[i+1];
-
-if (isempty(seat) || streq(seat, seat0)) {
-argv[0] = (char*) X_SERVER;
-execv(X_SERVER, argv);
-log_error(Failed to execute real X server: %m);
-goto fail;
-}
-
-r =
[systemd-devel] loginctl - multi-seats
I've just started following this discussion (so I don't know if it my reply will be correctly chained), and I would like to make some comments: * Starting with version 1.16, Xorg server no longer handles VTs if it was started as a non-seat0 X server i.e., if -seat option with a non-seat0 value was passed. So there's no need to pass option -sharevts or using systemd-multi-seat-x wrapper with this version. * Moreover, a new xorg.conf entry called MatchSeat was introduced in version 1.16. It allows configuring multiseat even if you're using non-KMS video drivers. For example, with you have a NVIDIA graphics card with binary driver, you can configure a secondary seat with the following xorg.conf: Section Device Identifier card0 Driver nvidia MatchSeat seat-1 EndSection provided you tag another suitable device (e.g. a USB hub) as master-of-seat and attach it to seat-1. About configuring multiseat using a single multi-head graphics card, the only current available way to do this is with nested X servers: 1. Start a bare X server properly configured to span all available monitors. It should be already running when your display manager service starts. 2. On top of this host X server, start a nested X server for each seat. The nested X server window geometry (size position) should be calculated to fit a given monitor. Currently there are two options for nested X servers: * Xephyr (must be built with option --enable-kdrive-evdev, supports input device coldplugging only) * Xorg + xf86-video-nested driver (early development, best option for multiseat) Next Xephyr release (1.17) will have support to a special -output NAME option which will make it fit a given output monitor. Desired NAME value can be obtained by running xrandr -display HOSTX-DISPLAY -q. I'm already using this scheme to set up a 3-seat system (1 integrated Intel graphics device for seat0 + 1 Silicon Motion SM501 dual-head PCI graphics card for the other seats). Since nested X servers don't touch VTs, I'm afraid of using such X servers with seat0. -- *Laércio de Sousa* *Orientador de Informática* *Escola Municipal Professor Eulálio Gruppi* *Rua Ismael da Silva Mello, 559, Mogi Moderno* *Mogi das Cruzes - SPCEP 08717-390* Telefone: (11) 4726-8313 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] seat1 ACL
Hi, It could be related to that lazy session-activation on non-seat0 seats introduced in systemd 208, and reverted by David Herrmann in version 209. See https://bugzilla.redhat.com/show_bug.cgi?id=1032014 Release 208-8 of Debian systemd packages already include David's patch: http://cgit.freedesktop.org/systemd/systemd/commit/?id=3fdb2494c1e24c0a020f5b54022d2c751fd26f50 http://metadata.ftp-master.debian.org/changelogs//main/s/systemd/systemd_208-8_changelog -- *Laércio de Sousa* *Orientador de Informática* *Escola Municipal Professor Eulálio Gruppi* *Rua Ismael da Silva Mello, 559, Mogi Moderno* *Mogi das Cruzes - SPCEP 08717-390* Telefone: (11) 4726-8313 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] loginctl - multi-seats
2014-08-25 14:14 GMT-03:00 Lennart Poettering lenn...@poettering.net: I worked with Ray to get support for this into gdm, I am not sure whether any other DM was ever updated to support this too. Stefan Brüns at openSUSE is currently working to bring logind multiseat support to KDM (based on original patch from Martin Briza at Red Hat): https://git.reviewboard.kde.org/r/112294/ Ubuntu Multiseat team is currently working with Robert Ancell to implement automatic multiseat support in LightDM: https://code.launchpad.net/~ubuntu-multiseat/lightdm/new-automatic-multiseat/+merge/231903 I can see no current work on supporting this feature in SDDM, but I believe Martin Briza will make it some day: https://github.com/sddm/sddm/issues/78 -- *Laércio de Sousa* *Orientador de Informática* *Escola Municipal Professor Eulálio Gruppi* *Rua Ismael da Silva Mello, 559, Mogi Moderno* *Mogi das Cruzes - SPCEP 08717-390* Telefone: (11) 4726-8313 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] loginctl - multi-seats
2014-08-25 15:13 GMT-03:00 Lennart Poettering lenn...@poettering.net: I think we can remove the entire wrapper now, right? Would be happy to merge a patch that kills it of. I agree. Or at least make systemd build option --disable-multi-seat-x the default for a while, until all major Linux distros ship with xorg-server 1.16. -- *Laércio de Sousa* *Orientador de Informática* *Escola Municipal Professor Eulálio Gruppi* *Rua Ismael da Silva Mello, 559, Mogi Moderno* *Mogi das Cruzes - SPCEP 08717-390* Telefone: (11) 4726-8313 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Ship new udev rules file to create per-seat symlinks for input devices
This rules file tells udev to create symlinks for input devices
(keyboard and mouse, at this moment) separated by seat, so it could
be easier for one to get quickly the devpath of a given input
device attached to a given seat.
Example: the keyboard attached to seat-foo will receive a symlink
with path /dev/input/by-seat/seat-foo.kbd-event
It can be very handful specially for Xephyr-based multiseat setups,
where input devpaths must be passed via command line options
like -keybd and -mouse.
---
Makefile.am | 3 ++-
src/login/74-seat-input.rules | 9 +
2 files changed, 11 insertions(+), 1 deletion(-)
create mode 100644 src/login/74-seat-input.rules
diff --git a/Makefile.am b/Makefile.am
index 79c49e6..b78df52 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -4262,7 +4262,8 @@ endif
dist_udevrules_DATA += \
src/login/70-uaccess.rules \
- src/login/70-power-switch.rules
+ src/login/70-power-switch.rules \
+ src/login/74-seat-input.rules
nodist_udevrules_DATA += \
src/login/71-seat.rules \
diff --git a/src/login/74-seat-input.rules b/src/login/74-seat-input.rules
new file mode 100644
index 000..059a8de
--- /dev/null
+++ b/src/login/74-seat-input.rules
@@ -0,0 +1,9 @@
+# Rules for seat0
+SUBSYSTEM==input, ENV{ID_SEAT}==, ENV{ID_INPUT_KEYBOARD}==1,
SYMLINK+=input/by-seat/seat0.kbd-event
+SUBSYSTEM==input, ENV{ID_SEAT}==, ENV{ID_INPUT_MOUSE}==1,
KERNEL==event*, SYMLINK+=input/by-seat/seat0.mouse-event
+SUBSYSTEM==input, ENV{ID_SEAT}==, ENV{ID_INPUT_MOUSE}==1,
KERNEL==mouse*, SYMLINK+=input/by-seat/seat0.mouse
+
+# Rules for other seats
+SUBSYSTEM==input, ENV{ID_SEAT}!=, ENV{ID_INPUT_KEYBOARD}==1,
SYMLINK+=input/by-seat/$env{ID_SEAT}.kbd-event
+SUBSYSTEM==input, ENV{ID_SEAT}!=, ENV{ID_INPUT_MOUSE}==1,
KERNEL==event*, SYMLINK+=input/by-seat/$env{ID_SEAT}.mouse-event
+SUBSYSTEM==input, ENV{ID_SEAT}!=, ENV{ID_INPUT_MOUSE}==1,
KERNEL==mouse*, SYMLINK+=input/by-seat/$env{ID_SEAT}.mouse
--
1.8.4.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Ship new udev rules file to create per-seat symlinks for input devices
Good point.
I used to append a $env{MINOR} to symlink names to avoid such ambiguities.
A side effect of this approach is that symlink names would change every
time the device is plugged in a different USB port, for example.
Would it be enough for you?
CANTATE DOMINO CANTICUM NOVUM
QUIA MIRABILIA FECIT
Laércio
2014-02-14 13:58 GMT-02:00 Lennart Poettering lenn...@poettering.net:
On Fri, 14.02.14 13:52, Laércio de Sousa (lbsous...@gmail.com) wrote:
This rules file tells udev to create symlinks for input devices
(keyboard and mouse, at this moment) separated by seat, so it could
be easier for one to get quickly the devpath of a given input
device attached to a given seat.
Example: the keyboard attached to seat-foo will receive a symlink
with path /dev/input/by-seat/seat-foo.kbd-event
It can be very handful specially for Xephyr-based multiseat setups,
where input devpaths must be passed via command line options
like -keybd and -mouse.
Hmm, modern systems tend to have multiple keyboards and mice. For
example, mine has a touchscreen and a touchpad as mouse and a a couple
acpi devices plus a real kbd, plus some laptop-specific keys all exposed
as keyboards. Trying to create a single symlink for all of this appears
to be doomed to fail?
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-multi-seat-x deprecation is near...
Thanks for the patch, Zbyszek! CANTATE DOMINO CANTICUM NOVUM QUIA MIRABILIA FECIT Laércio 2013/11/28 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl On Thu, Nov 28, 2013 at 01:33:29PM -0200, Laércio de Sousa wrote: If/when these patches are released, then systemd-multi-seat-x, in its current form, will be no longer necessary. So, unless you have another plans for this wrapper, I would like to suggest that you make its build optional in future releases of systemd (if it's not already optional). It can now be disabled with --disable-multi-seat-x. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-multi-seat-x deprecation is near...
Hi there! I've submitted some patches to xorg-devel to fill the remaining gaps which make current sytemd-multi-seat-x wrapper still needed in some multiseat setups. One of these patches was already merged into upstream and should be released in xorg-server v1.15 (see http://cgit.freedesktop.org/xorg/xserver/commit/?id=c73c36b537f996574628e69681833ea37dec2b6e ). There are other two alternative patches, that fill the other gap, currently waiting for review: This one: http://lists.x.org/archives/xorg-devel/2013-November/038748.html OR This one (preferrable): http://lists.x.org/archives/xorg-devel/2013-November/038765.html If/when these patches are released, then systemd-multi-seat-x, in its current form, will be no longer necessary. So, unless you have another plans for this wrapper, I would like to suggest that you make its build optional in future releases of systemd (if it's not already optional). CANTATE DOMINO CANTICUM NOVUM QUIA MIRABILIA FECIT Laércio ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd 208:trouble with inactive user sessions at non-seat0 seats
David,
Looking at GDM debug and gdm-simple-slave.c source file, as well as
loginctl show-seat output. I guess that GDM only requests user session
activation for seats with CanMultiSession=yes, but currently systemd-logind
still sets CanMultiSession=no for my non-seat0 seats.
Does seat_can_multi_session() heuristics need some improvement since
generic multi-session was introduced?
I've applied your last patch. I confirm it solves my problem for now.
Thanks for all, and keep the good work!
CANTATE DOMINO CANTICUM NOVUM
QUIA MIRABILIA FECIT
Laércio
2013/11/26 David Herrmann dh.herrm...@gmail.com
Hi
On Tue, Nov 26, 2013 at 11:45 AM, Laércio de Sousa lbsous...@gmail.com
wrote:
Hi David!
I just tested your patch, and unfortunately it didn't work. However, I
guess
what could be the question.
If I understand correctly, your patch applies for the case we have no
active
session at all in a non-seat0 seat. However, I do have an active session
in
my non-seat0 seat --- the one GDM opens to show the greeter. The
question is
that, when a user logs in at a non-seat0 seat, GDM (or whatever) should
activate automatically the new user session, sending the greeter session
to
the background while it's in state closing, as we have for seat0. In my
current setup, it doesn't occur: in a non-seat0 seat, the closing
greeter
session remains active, while the new user session starts at background
(inactive).
If I activate manually the user session (loginctl activate session),
the
converse occurs: when the user logs out, its closing user session
remains
active, while the new greeter session starts at background (inactive).
Just for comparison: if I configure autologin for GDM (to avoid opening
the
greeter session), or use multiseat-patched KDM (which doesn't open
greeter
sessions), the user session starts at foreground, as expected, even
without
this patch.
That gdm behavior is actually weird. It should explicitly request the
new session to become active. There is no reason for logind to
*assume* the new session should be activated automatically.. hmm.
The appended patch reverts the new behavior. Can you give it a try? I
actually cannot get gdm to pick up my additional seats.. and looking
into the monstrosity called gdm-source-base I have no clue what it
does. If you can confirm that this resets the behavior, I will apply
it so we don't break existing setups.
I will figure out something else for new multi-session capable seats.
Thanks
David
diff --git a/src/login/logind-seat.c b/src/login/logind-seat.c
index b30c4ce..ca0e8d7 100644
--- a/src/login/logind-seat.c
+++ b/src/login/logind-seat.c
@@ -413,8 +413,8 @@ int seat_attach_session(Seat *s, Session *session) {
seat_send_changed(s, Sessions, NULL);
/* On seats with VTs, the VT logic defines which session is
active. On
- * seats without VTs, we automatically activate the first
session. */
-if (!seat_has_vts(s) !s-active)
+ * seats without VTs, we automatically activate new sessions. */
+if (!seat_has_vts(s))
seat_set_active(s, session);
return 0;
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd 208:trouble with inactive user sessions at non-seat0 seats
Hi there! I'm testing both Fedora 20 Beta and openSUSE 13.1 in my multiseat system (with GNOME 3.10, GDM 3.10.0.1 and systemd 208). I'm currently observing a strange behaviour which didn't occur in previous distro release (with GNOME 3.8.4 and systemd 204). When I boot my system, gdm greeter session at both seat0 and non-seat0 seats are active, as expected. However, when a user logs in at a non-seat0 seat, the user session gets inactive. Nevertheless, I can activate it manually with command loginctl activate user-session-id, but if that user logs out, the new greeter session now becomes inactive. I suspect this strange behaviour is related to that generic multi-session support introduced in systemd 208. I can see that, when a user logs in, the greeter and user sessions coexist for a while, one at closing state and the other at online state, depending on whether the user logs in or out. What could it be? Lack of generic multi-session support in GDM? CANTATE DOMINO CANTICUM NOVUM QUIA MIRABILIA FECIT Laércio ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Xorg+logind+DM issue: inactive graphical session for seat0
Hello there! I'm posting this question in both systemd-devel and xorg-devel lists because I want to know each one's opinion about it. In some multiseat setups involving multiple video cards, sometimes we get the following error: depending on the display manager currently used, systemd-logind gives us an INACTIVE graphical session for seat0. An interesting analysis of the problem can be found at https://bugzilla.redhat.com/show_bug.cgi?id=1018196. To summarize, due to some race condition between seat0 and non-seat0 seats, a non-seat0 X server can steal the VT expected by seat0 X server. In this case, unless XDG_VTNR is explicitly defined by display manager, the pam_systemd module fails to infer the correct VT for seat0 X server (i.e., the one corresponding to vtXX command line argument), returning XDG_VTNR=0 to seat0's graphic session, which causes all the trouble. Joseph Nuzman, who opened the bug above, suggests some approachs to avoid this problem, and I really want to know what do you think about them: * DMs should always set the XDG_VTNR variable for seat0. GDM currently doesn't set this variable, but a forked version of LightDM, maintained by Ubuntu Multiseat team (merging into upstream is under consideration), does it. * pam_systemd should have its heuristic to infer the seat0 VT number improved. Maybe parsing X server /proc/pid/cmdline for a vtXX argument. * DMs should ensure that seat0 X server starts before any other one. Stefan Brüns has provided a similar approach for KDM on Fedora/openSUSE: it ensures seat0 X server starts at the same VT previously used by Plymouth. I would append another approach to the list: * For non-seat0 seats, X server should open no VT at all. Currently, even with -sharevts option, it seems Xorg does open a VT, although it can't control this. CANTATE DOMINO CANTICUM NOVUM QUIA MIRABILIA FECIT Laércio ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
