Re: [systemd-devel] logind: multiseat without framebuffer graphic cards
Please rebase to current git! We merge new stuff like this only into the git
version.
I'm sorry. The previous patch was for F17. Here is one for the git
version.
As mentioned, for F19 we want to get rid of that. systemd-multi-seat-x
was only intended to be a temporary work-around until X learned to use
-seat for enumerating video devices. In F18 the code of s-m-s-x is
already much shorter.
I saw it after I had download the git version. But s-m-s-x in F18 is
still overriding a xorg.conf file so seems any static configuration will
be impossible. May be to learn it not to override conf in some cases?
2. Make 'loginctl seat-status' to display which device is a
seat-master
This would be useful, i.e. show a little asterisk or so next to the
master devices of a seat.
4. Now the case is not resolved if two or more seat-master devices
exist
in the same seat and one of them becomes unplugged. Seems according the
login.c, manager_process_seat_device function will destroy the seat, but
this behavior does not look like a correct. The same issue exists with
framebuffer devices.
Hmm, so, the rule should definitely be that as long as at least one
master device is around logind should keep the seat around.
Yes, it should exactly.
These two issues (2 and 4) require logind to keep bool isMaster in struct
Device and make manager_process_seat_device to traverse the seat device list. I
could make these changes.
Unfortunally, I am not familiar with dbus so I've haven't yet realised how
'loginctl seat-status' works, so (2) would demands more time for me.
Newer X
subscribes to udev, and can properly deal with graphics cards appearing
and going away, and will merge them appropriately.
But logind should keep the seat as active and shoudn't send SeatRemoved
signals until no master devices left .
3. Make 'loginctl attach' capable of adding a device as a seat-master.
For example
I don't think this is really necessary or even a good idea. A master
device should just mean that some device is sufficient for a seat to
exist. But that's property of a device/driver, not so much configuration
of the user, hence I think there is no point in adding high-level
commands for this.
May be. The workaround (for closed source video) - to patch
72-seat-*.rules manually - is possible, but does not look like a nice.
Changing the all manner of initialising video (with udev instead of with
X) does not seem feasible the next XX years.
5. An issue is not related to framebuffer but to user access privileges:
users cann't access /dev/snd/seq device in a multi-seat environment.
This sounds as if it should be tagged with uaccess, so that it is
managed by dynamic ACLs as sessoins become active and inactive.
udevadm shows it is tagged with uaccess, but there is no ID_SEAT
property
P: /devices/virtual/sound/seq
N: snd/seq
E: DEVNAME=/dev/snd/seq
E: DEVPATH=/devices/virtual/sound/seq
E: MAJOR=116
E: MINOR=1
E: SUBSYSTEM=sound
E: TAGS=:uaccess:
E: USEC_INITIALIZED=5155039
But this virtual device shoud be shared between all seats and should
be accessible from all active sessions. Does logind/pam can handle this
approach?
Some others multiseat-related issues detected (I'm not shure that
systemd is responsable for them) :
6. When the user press Ctrl+Alt+fN on the seat1, it switchs tty on the
seat0.
7. When seat0 is switched into the text mode (ex. after Ctrl+Alt+F2),
all keys typed on seat1 is displayed on Seat0. It seems as a serious
security vulnerability, because seat0 user can see the login password of
seat1 typed at GDM login.
The workaround is to start 'X -seat0 -sharevts', but it disables
vt-switching on seat0 completelly.
Oleg.
From: Oleg Samarin osamari...@gmail.com
Subject: [PATCH] logind: multi-seat without framebuffer devices
The seat is now activated by any device with udev tag seat-master
All framebuffer devices have this tag
multi-seat-x : if the seat does not have a framebuffer device, runs X as a proxy, adding -sharevts only
if the seat has a framebuffer device, makes a special config for X (like it did before)
diff -Naur systemd.old/src/login/71-seat.rules.in systemd.new/src/login/71-seat.rules.in
--- systemd.old/src/login/71-seat.rules.in 2012-11-25 17:51:38.0 +0400
+++ systemd.new/src/login/71-seat.rules.in 2012-11-25 18:56:07.0 +0400
@@ -11,6 +11,7 @@
SUBSYSTEM==sound, KERNEL==card*, TAG+=seat
SUBSYSTEM==input, KERNEL==input*, TAG+=seat
SUBSYSTEM==graphics, KERNEL==fb[0-9]*, TAG+=seat
+SUBSYSTEM==graphics, KERNEL==fb[0-9]*, TAG+=seat-master
SUBSYSTEM==usb, ATTR{bDeviceClass}==09, TAG+=seat
# 'Plugable' USB hub, sound, network, graphics adapter
diff -Naur systemd.old/src/login/logind.c systemd.new/src/login/logind.c
--- systemd.old/src/login/logind.c 2012-11-25 17:51:38.0 +0400
+++ systemd.new/src/login/logind.c 2012-11-25 18:58:07.0 +0400
@@ -450,11 +450,7 @@
goto finish;
}
-r =
Re: [systemd-devel] logind: multiseat without framebuffer graphic cards
On Sun, Nov 25, 2012 at 6:35 PM, Oleg Samarin osamari...@gmail.com wrote: В Вс., 25/11/2012 в 02:21 +0100, Kay Sievers пишет: On Sat, Nov 24, 2012 at 10:46 PM, Lennart Poettering lenn...@poettering.net wrote: This sounds as if it should be tagged with uaccess, so that it is managed by dynamic ACLs as sessoins become active and inactive. Kay, what's the story behind /dev/snd/seq and ACLs? Should work fine when the driver is loaded. The module is usually not loaded though. If snd_seq is not loaded, then /dev/snd/seq has no ACL at all. Right. As mentioned, it is a known limitation. After loading snd_seq /dev/snd/seq becomes accessible in a single seat enviroment. But after configuring seat1 it stops working on both seat0 and seat1. Sure, only one seat has access to one and the same device at a time. The auto-loading on user access by the kernel does not trigger, because the ACL only gets applied to a real device, not a dead device node. So, either the primary permissions of the node need to be relaxed, the module needs to be always force-loaded, or the ACL setting logic would need to be changed to include dead nodes without a device. F17 has a bug causes snd_seq is not loaded on boot. But after I used a workaround (placing 'install snd-pcm /usr/sbin/modprobe --ignore-install snd-pcm /usr/sbin/modprobe snd-seq' to /etc/modprobe.d/dist-alsa.conf), /dev/snd/seq started working A single entry in /etc/modules-load.d/ (man modules-load.d) sounds like the better option. but only in single-seat environment. Right, there is currently not support at all for sharing devices across multiple users. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind: multiseat without framebuffer graphic cards
Am 23.11.2012 18:18, schrieb Lennart Poettering: On Thu, 22.11.12 13:27, Thomas Bächler (tho...@archlinux.org) wrote: For me, the major problem is that the selection of seat master devices is hard-coded in logind (it selects devices of type graphics from udev, [1]). Step 1 would be to move that to a udev rule: Add a seatmaster tag to all graphics devices and have logind select those (this would actually remove three LOC in logind.c, and change one line). Now, an admin could give this tag to any device. This fix is very easy, non-invasive and would make logind's multi-seat support much more flexible (it also allows an admin to do very stupid things, but I don't see any reason to prevent that). seat-master sounds like a good name for this. I'd be happy to merge a patch that changes logind so that it watches for devices tagged with this, and spawns an X server the moment such a device appears. If nobody beats me to it, I'll try to create a patch for this in the next few days. The second step is to make multi-seat-x support custom configurations: If an X server is to be spawned on on a seat named seatN and /etc/X11/xorg.conf_seatN exists, then that configuration file is used and multi-seat-x doesn't generate one. (Over time, maybe multi-seat-x can be extended to support more setups automatically, but that is a very low priority for me, as figuring out the correct configuration with the proprietary nvidia driver is not straight-forward.) Can't this be done in X instead? IIRC X already has some matching thing in the configuration file format. Maybe this could be extended to allow matching by seat name? Then, people could just drop per-seat configuration as normal snippets into /etc/X11/xorg.conf.d/ and add a match line to them and that would be it? Fine with me. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind: multiseat without framebuffer graphic cards
But nigther user of seat0 nor user of seat1 can access it even another user is not working with it, even no user is logged on anothe seat. I made more testing and found, that /dev/snd/seq is accessible for any user, logged in on the seat0, but not to one logged on the seat1. After reading login_acl.c, seems, the reason is the /dev/snd/seq device has 'uaccess' tag, but do not have 'ID_SEAT' property. So logind assumes this device belongs to seat0. I think logind should treat such device as shared and accessible with all seats. My idea is to treat all devices with 'uaccess' tag but without 'seat' tag as shared. Lennart, what is your opinion on this? If nobody is opposite, this Saturday I could try to fix it in login_acl and to prepare a patch. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind: multiseat without framebuffer graphic cards
В Пт., 23/11/2012 в 18:22 +0100, Lennart Poettering пишет:
OK. So we need two changes:
(1). Introduce a new udev tag that means master device for the seat.
Support it with logind.c. Add an udev rule that sets this tag for all
framebuffer device
Yes, and please name this tag seat-master.
The patch is ready (see attached file). I've tested it on my computer
with two nvidia cards and closed source driver ant on a virtualbox with
one framebuffer device. Seems everything works. But I coudn't test it
with two real framebuffer devices.
(2). multi-seat-x should not trigger an error if there is no framebufer
device exist on the seat. It is a temporary stuff until X can get device
from -seat, so it may look for a specially named config file or just
start X without any addition parameters (or with -sharevts only)
I'd much prefer if this was done in X instead. i.e. via matching the
-seat parameter when parsing configuration files.
The problem is not the -seat parameter, but the following:
1. The path /usr/lib/systemd/systemd-multi-seat-x path is hardcode in
GDM for all seats except seat0
2. If the seat does not contain а framebuffer device then
systemd-multi-seat-x stops with Failed to find device node for seat %
s.
So some minimal changes of multi-seat-x are necessary: if there is no
framebuffer device then it just starts X with -sharevts, but without
making a config file. This change is also included in the attached patch
i.e. xorg.conf currently already knows:
MatchProduct
MatchDevicePath
MatchTag
MatchDriver
Maybe introducing a MatchSeat construct in this style would be the best
solution?
It is a good idea and I support it. But I think better it should be
discussed at Xorg rather here.
The next possible activities related to systemd and multi-seat might be:
1. Describe the tag seat-master at
http://www.freedesktop.org/wiki/Software/systemd/multiseat
I do not have a write access on this page, but I can post changed pieces
of text here.
2. Make 'loginctl seat-status' to display which device is a seat-master
3. Make 'loginctl attach' capable of adding a device as a seat-master.
For example
# loginctl attach -master
seat1 /sys/devices/pci:00/:00:06.0/:02:00.1/sound/card1
It would create an udev rule with
ENV{ID_SEAT}=seat1, TAG+=seat-master
4. Now the case is not resolved if two or more seat-master devices exist
in the same seat and one of them becomes unplugged. Seems according the
login.c, manager_process_seat_device function will destroy the seat, but
this behavior does not look like a correct. The same issue exists with
framebuffer devices.
5. An issue is not related to framebuffer but to user access privileges:
users cann't access /dev/snd/seq device in a multi-seat environment.
This device is used by all MIDI applications, so they do not work (the
workaround is to include users to the audio group, but it causes all
sound card are accessible regardless their seats).
If nobody is opposite, I'm planning to work with these issues and I'd
like to meet any related opinions.
Oleg.
From: Oleg Samarin osamari...@gmail.com
Subject: [PATCH] logind: multi-seat without framebuffer devices
The seat is now activated by any device with udev tag seat-master
All framebuffer devices have this tag
multi-seat-x : if the seat does not have a framebuffer device, runs X as a proxy, adding -sharevts only
if the seat has a framebuffer device, makes a special config for X (like it did before)
diff -Naur systemd-44.old/src/login/71-seat.rules.in systemd-44.new/src/login/71-seat.rules.in
--- systemd-44.old/src/login/71-seat.rules.in 2012-11-23 23:35:24.0 +0400
+++ systemd-44.new/src/login/71-seat.rules.in 2012-11-23 23:51:48.076271381 +0400
@@ -11,6 +11,7 @@
SUBSYSTEM==sound, KERNEL==card*, TAG+=seat
SUBSYSTEM==input, KERNEL==input*, TAG+=seat
SUBSYSTEM==graphics, KERNEL==fb[0-9]*, TAG+=seat
+SUBSYSTEM==graphics, KERNEL==fb[0-9]*, TAG+=seat-master
SUBSYSTEM==usb, ATTR{bDeviceClass}==09, TAG+=seat
# 'Plugable' USB hub, sound, network, graphics adapter
diff -Naur systemd-44.old/src/login/logind.c systemd-44.new/src/login/logind.c
--- systemd-44.old/src/login/logind.c 2012-11-23 23:35:27.0 +0400
+++ systemd-44.new/src/login/logind.c 2012-11-24 19:30:28.0 +0400
@@ -372,11 +372,7 @@
goto finish;
}
-r = udev_enumerate_add_match_subsystem(e, graphics);
-if (r 0)
-goto finish;
-
-r = udev_enumerate_add_match_tag(e, seat);
+r = udev_enumerate_add_match_tag(e, seat-master);
if (r 0)
goto finish;
@@ -1124,11 +1120,7 @@
if (!m-udev_seat_monitor)
return -ENOMEM;
-r = udev_monitor_filter_add_match_tag(m-udev_seat_monitor, seat);
-if (r 0)
-return r;
-
-r = udev_monitor_filter_add_match_subsystem_devtype(m-udev_seat_monitor, graphics, NULL);
+
Re: [systemd-devel] logind: multiseat without framebuffer graphic cards
On Sat, 24.11.12 23:12, Олег Самарин (osamari...@gmail.com) wrote: В Пт., 23/11/2012 в 18:22 +0100, Lennart Poettering пишет: OK. So we need two changes: (1). Introduce a new udev tag that means master device for the seat. Support it with logind.c. Add an udev rule that sets this tag for all framebuffer device Yes, and please name this tag seat-master. The patch is ready (see attached file). I've tested it on my computer with two nvidia cards and closed source driver ant on a virtualbox with one framebuffer device. Seems everything works. But I coudn't test it with two real framebuffer devices. Please rebase to current git! We merge new stuff like this only into the git version. (2). multi-seat-x should not trigger an error if there is no framebufer device exist on the seat. It is a temporary stuff until X can get device from -seat, so it may look for a specially named config file or just start X without any addition parameters (or with -sharevts only) I'd much prefer if this was done in X instead. i.e. via matching the -seat parameter when parsing configuration files. The problem is not the -seat parameter, but the following: 1. The path /usr/lib/systemd/systemd-multi-seat-x path is hardcode in GDM for all seats except seat0 As mentioned, for F19 we want to get rid of that. systemd-multi-seat-x was only intended to be a temporary work-around until X learned to use -seat for enumerating video devices. In F18 the code of s-m-s-x is already much shorter. 1. Describe the tag seat-master at http://www.freedesktop.org/wiki/Software/systemd/multiseat I do not have a write access on this page, but I can post changed pieces of text here. It's a Wiki, you can simply register there and edit freely. That said, please don't make any changes before the respective code is not merged into systemd yet. 2. Make 'loginctl seat-status' to display which device is a seat-master This would be useful, i.e. show a little asterisk or so next to the master devices of a seat. 3. Make 'loginctl attach' capable of adding a device as a seat-master. For example I don't think this is really necessary or even a good idea. A master device should just mean that some device is sufficient for a seat to exist. But that's property of a device/driver, not so much configuration of the user, hence I think there is no point in adding high-level commands for this. 4. Now the case is not resolved if two or more seat-master devices exist in the same seat and one of them becomes unplugged. Seems according the login.c, manager_process_seat_device function will destroy the seat, but this behavior does not look like a correct. The same issue exists with framebuffer devices. Hmm, so, the rule should definitely be that as long as at least one master device is around logind should keep the seat around. Newer X subscribes to udev, and can properly deal with graphics cards appearing and going away, and will merge them appropriately. 5. An issue is not related to framebuffer but to user access privileges: users cann't access /dev/snd/seq device in a multi-seat environment. This device is used by all MIDI applications, so they do not work (the workaround is to include users to the audio group, but it causes all sound card are accessible regardless their seats). This sounds as if it should be tagged with uaccess, so that it is managed by dynamic ACLs as sessoins become active and inactive. Kay, what's the story behind /dev/snd/seq and ACLs? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind: multiseat without framebuffer graphic cards
'Twas brillig, and Lennart Poettering at 23/11/12 17:18 did gyre and gimble: On Thu, 22.11.12 13:27, Thomas Bächler (tho...@archlinux.org) wrote: For me, the major problem is that the selection of seat master devices is hard-coded in logind (it selects devices of type graphics from udev, [1]). Step 1 would be to move that to a udev rule: Add a seatmaster tag to all graphics devices and have logind select those (this would actually remove three LOC in logind.c, and change one line). Now, an admin could give this tag to any device. This fix is very easy, non-invasive and would make logind's multi-seat support much more flexible (it also allows an admin to do very stupid things, but I don't see any reason to prevent that). seat-master sounds like a good name for this. I'd be happy to merge a patch that changes logind so that it watches for devices tagged with this, and spawns an X server the moment such a device appears. Speaking of which, is there any reason the gdm does the seat watching right now and takes care of spawning new seats... Shouldn't systemd start gdm in the same way it starts getty's? i.e. via a templated unit? getty@tty1.service, gdm@tty2.service etc.? Or is this exactly what you're suggesting? Col -- Colin Guthrie gmane(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/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind: multiseat without framebuffer graphic cards
'Twas brillig, and Lennart Poettering at 24/11/12 21:46 did gyre and gimble: 5. An issue is not related to framebuffer but to user access privileges: users cann't access /dev/snd/seq device in a multi-seat environment. This device is used by all MIDI applications, so they do not work (the workaround is to include users to the audio group, but it causes all sound card are accessible regardless their seats). This sounds as if it should be tagged with uaccess, so that it is managed by dynamic ACLs as sessoins become active and inactive. Kay, what's the story behind /dev/snd/seq and ACLs? Yeah I've occasionally had bug reports about seq and how it was never included in the ACLs. Would be nice to see this solved in some capacity even better for multi-seat. Col -- Colin Guthrie gmane(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/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind: multiseat without framebuffer graphic cards
On Sat, 24.11.12 22:34, Colin Guthrie (gm...@colin.guthr.ie) wrote: seat-master sounds like a good name for this. I'd be happy to merge a patch that changes logind so that it watches for devices tagged with this, and spawns an X server the moment such a device appears. Speaking of which, is there any reason the gdm does the seat watching right now and takes care of spawning new seats... Shouldn't systemd start gdm in the same way it starts getty's? i.e. via a templated unit? getty@tty1.service, gdm@tty2.service etc.? Or is this exactly what you're suggesting? Well, that's a fundamental question whether you want one display manager instance managing all seats, or many instances, one for each seat. Both approaches are valid. However I'd vote for the one-dm-rules-them-all approach because it's how we always did things, and is probably a bit nicer, since for multi-session seats where fast-user-switching is allowed you probably want a single daemon which properly handles tty switches. And if you have a single daemon managing multiple sessions on the same seat, then it's probably a good idea to just make it manage multiple sessions on many seats, too. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind: multiseat without framebuffer graphic cards
On Sat, Nov 24, 2012 at 10:46 PM, Lennart Poettering lenn...@poettering.net wrote: This sounds as if it should be tagged with uaccess, so that it is managed by dynamic ACLs as sessoins become active and inactive. Kay, what's the story behind /dev/snd/seq and ACLs? Should work fine when the driver is loaded. The module is usually not loaded though. The auto-loading on user access by the kernel does not trigger, because the ACL only gets applied to a real device, not a dead device node. So, either the primary permissions of the node need to be relaxed, the module needs to be always force-loaded, or the ACL setting logic would need to be changed to include dead nodes without a device. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind: multiseat without framebuffer graphic cards
On Thu, 22.11.12 13:27, Thomas Bächler (tho...@archlinux.org) wrote: For me, the major problem is that the selection of seat master devices is hard-coded in logind (it selects devices of type graphics from udev, [1]). Step 1 would be to move that to a udev rule: Add a seatmaster tag to all graphics devices and have logind select those (this would actually remove three LOC in logind.c, and change one line). Now, an admin could give this tag to any device. This fix is very easy, non-invasive and would make logind's multi-seat support much more flexible (it also allows an admin to do very stupid things, but I don't see any reason to prevent that). seat-master sounds like a good name for this. I'd be happy to merge a patch that changes logind so that it watches for devices tagged with this, and spawns an X server the moment such a device appears. The second step is to make multi-seat-x support custom configurations: If an X server is to be spawned on on a seat named seatN and /etc/X11/xorg.conf_seatN exists, then that configuration file is used and multi-seat-x doesn't generate one. (Over time, maybe multi-seat-x can be extended to support more setups automatically, but that is a very low priority for me, as figuring out the correct configuration with the proprietary nvidia driver is not straight-forward.) Can't this be done in X instead? IIRC X already has some matching thing in the configuration file format. Maybe this could be extended to allow matching by seat name? Then, people could just drop per-seat configuration as normal snippets into /etc/X11/xorg.conf.d/ and add a match line to them and that would be it? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind: multiseat without framebuffer graphic cards
On Thu, 22.11.12 23:04, Oleg Samarin (osamari...@gmail.com) wrote: В Ср., 21/11/2012 в 20:23 +0100, Lennart Poettering пишет: I think there are other ways thinkable, where we don't have to add explicit nvidia-compatibility switches. For example, instead of explicitly watching for fb devices to show up before we consider a seat to be around, we could instead look for devices that are tagged with a special tag (tag as in udev's TAG= construct) -- we'd then tag all fb devices out-of-the-box this way, and people who want to use the nvidia binary driver can attach that tag to some kernel device the nvidia driver exposes, but I wouldn't have to care about that, and systemd upstream wouldn't need to know what people do locally. And maybe you could even convince Nvidia to ship the udev rule that attaches this tag in their drivers. By doing things this way we'd not introduce the race that your patch would introduce, but we'd not hardcode anything directly to fb devices. Note that in systemd we generally try to fix this things properly, and not work-around things. Now, your global swicth didn't appear as a proper fix to me, due to the race issues. But the solution with a udev tag otoh sounds like a worthwile fix that makes logind cleaner -- and which as a side-effect allows you to integrate things with your nvidia driver. Does that make some sense? OK. So we need two changes: (1). Introduce a new udev tag that means master device for the seat. Support it with logind.c. Add an udev rule that sets this tag for all framebuffer device Yes, and please name this tag seat-master. (2). multi-seat-x should not trigger an error if there is no framebufer device exist on the seat. It is a temporary stuff until X can get device from -seat, so it may look for a specially named config file or just start X without any addition parameters (or with -sharevts only) I'd much prefer if this was done in X instead. i.e. via matching the -seat parameter when parsing configuration files. i.e. xorg.conf currently already knows: MatchProduct MatchDevicePath MatchTag MatchDriver Maybe introducing a MatchSeat construct in this style would be the best solution? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind: multiseat without framebuffer graphic cards
Am 21.11.2012 20:23, schrieb Lennart Poettering: Ahum, we wrote this with modern in-kernel drivers in mind, really. I understand that people want to run this stuff with the closed-source binary drivers, but due to the closed-source-ness this is really not that high on my TODO list and is not as easy to implement as it sounds. I have been looking into this topic, but lacked the time to finish the thought. For me, the major problem is that the selection of seat master devices is hard-coded in logind (it selects devices of type graphics from udev, [1]). Step 1 would be to move that to a udev rule: Add a seatmaster tag to all graphics devices and have logind select those (this would actually remove three LOC in logind.c, and change one line). Now, an admin could give this tag to any device. This fix is very easy, non-invasive and would make logind's multi-seat support much more flexible (it also allows an admin to do very stupid things, but I don't see any reason to prevent that). The second step is to make multi-seat-x support custom configurations: If an X server is to be spawned on on a seat named seatN and /etc/X11/xorg.conf_seatN exists, then that configuration file is used and multi-seat-x doesn't generate one. (Over time, maybe multi-seat-x can be extended to support more setups automatically, but that is a very low priority for me, as figuring out the correct configuration with the proprietary nvidia driver is not straight-forward.) This wouldn't work with dynamically appearing and disappearing seats, and it wouldn't be fully automatic, but that isn't my use case anyway: I have computers with two NVidia PCIe cards, and thus always have exactly two seats. I simply launch two X servers manually with the correct configuration from KDM. This setup works perfectly right now, except that logind doesn't recognize them as separate seats (there is no 'graphics' device present, so I cannot even create a second seat). The first change I outlined above would solve almost all my problems (I'd still have to cheat KDM into passing the correct XDG_SEAT, as it doesn't fully support logind yet - but I can do that without any help from systemd/logind). [1] http://cgit.freedesktop.org/systemd/systemd/tree/src/login/logind.c#n453 signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind: multiseat without framebuffer graphic cards
Am 21.11.2012 20:23, schrieb Lennart Poettering: I think there are other ways thinkable, where we don't have to add explicit nvidia-compatibility switches. For example, instead of explicitly watching for fb devices to show up before we consider a seat to be around, we could instead look for devices that are tagged with a special tag (tag as in udev's TAG= construct) -- we'd then tag all fb devices out-of-the-box this way, and people who want to use the nvidia binary driver can attach that tag to some kernel device the nvidia driver exposes, but I wouldn't have to care about that, and systemd upstream wouldn't need to know what people do locally. Oh, I replied before I completely read your email, so what I wrote earlier essentially says the same thing that you just said. I was meaning to send a patch that does exactly this for a while, but never got around to do it. This is exactly what I need for my custom nvidia setups to integrate into logind. I would be very happy to see this change in logind. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind: multiseat without framebuffer graphic cards
В Ср., 21/11/2012 в 20:23 +0100, Lennart Poettering пишет: I think there are other ways thinkable, where we don't have to add explicit nvidia-compatibility switches. For example, instead of explicitly watching for fb devices to show up before we consider a seat to be around, we could instead look for devices that are tagged with a special tag (tag as in udev's TAG= construct) -- we'd then tag all fb devices out-of-the-box this way, and people who want to use the nvidia binary driver can attach that tag to some kernel device the nvidia driver exposes, but I wouldn't have to care about that, and systemd upstream wouldn't need to know what people do locally. And maybe you could even convince Nvidia to ship the udev rule that attaches this tag in their drivers. By doing things this way we'd not introduce the race that your patch would introduce, but we'd not hardcode anything directly to fb devices. Note that in systemd we generally try to fix this things properly, and not work-around things. Now, your global swicth didn't appear as a proper fix to me, due to the race issues. But the solution with a udev tag otoh sounds like a worthwile fix that makes logind cleaner -- and which as a side-effect allows you to integrate things with your nvidia driver. Does that make some sense? OK. So we need two changes: (1). Introduce a new udev tag that means master device for the seat. Support it with logind.c. Add an udev rule that sets this tag for all framebuffer device (2). multi-seat-x should not trigger an error if there is no framebufer device exist on the seat. It is a temporary stuff until X can get device from -seat, so it may look for a specially named config file or just start X without any addition parameters (or with -sharevts only) This saturday I will be capable of creating some patch for (1). My questions: 1. Which tag name would be better? construct? seatmaster? Something else? 2. What should be right behavior if there are two or more seat masters in a seat? Create a seat if any of them exists and remove the seat if there are no more seat-masters on the seat? Oleg. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] logind: multiseat without framebuffer graphic cards
Hi!
I have a Fedora 17 system with two nvidia videocards, two screens, two
keyboards and two mouses. I've tried to setup multi-seat on it following
this article:
http://code.lexarcana.com/blog/2012/06/17/simple-multiseat-setup-on-fedora-17/.
But without success.
The article propose to create a new seat by attaching a framebuffer device to
the it:
Unfortunally, there are no any devices whose path end with /drm/card1 or
/graphics/fb1 in my system ('loginctl seat-status seat0' does not show any).
These paths arrive only after loading the open-source driver (nouveau), but not
with Nvidia proprietary driver.
Furthermore, the right way of loading graphic driver is after starting
X-server, not before it. So logind should inform gdm about new seats before gdm
starts X-servers that loads nvidia driver.
My idea is
1. make static configuration of videocards and monitors in xorg.conf
2. dynamically add inputdevices according to the site udev rules
3. learn Xorg to select proper ServerLayout section according the -seat
parameter
I created two patches (one for systemd-44-21) and another for
xorg-x11-server-1.12.3-2) that implemented this idea.
The first patch - systemd-logind-site-without-graphics - introduces the new
systemd-logind.conf option: SeatWithoutGraphics with default value no. But
the value yes allows logind to create a new seat by attaching any device for
it, not only graphics.
The second patch - xserver-1.12.3-xorg-seat-layout - introduces the
new ServerLayout option - Seat. If Xorg runs with only -seat command line
parameter, without -layout (gdm starts it in this manner), it tries to find a
layout with the value of Seat is equal to the value of -seat parameter
After applying these patches seems everything works.
The way to setup:
1. install the pached packages systemd and xorg-x11-server-Xorg
2. create xorg.conf with several ServerLayout sections and Seat options
specifying what seat it belongs. It is not necessary to add InputDevices to the
layouts.
3. Add SeatWithoutGraphics=yes to /etc/systemd/systemd-logind.conf
4. Restart service systemd-logind.service
5. Attach any devices (for example, USB hubs) to your seats seat1, seat2 and so
on. All the seats will be created by logind
6. Restart gdm (init 3 init 5)
7. All displays will shows the gdm user-selection screen.
I've created a bugs at https://bugzilla.redhat.com/show_bug.cgi?id=878605. It
also resolves
I'd like if my patch will be resolved upstream.
Oleg.
From: Oleg Samarin osamari...@gmail.com
Subject: [PATCH] logind: creating a site without graphics
Added capability of creating a new site without graphic card
diff -Naur systemd-44.old/src/login/logind.c systemd-44/src/login/logind.c
--- systemd-44.old/src/login/logind.c 2012-11-15 22:31:51.0 +0400
+++ systemd-44/src/login/logind.c 2012-11-15 22:36:58.343888212 +0400
@@ -321,7 +321,11 @@
if (!device)
return 0;
-seat_add_to_gc_queue(device-seat);
+LIST_REMOVE(Device, devices, device-seat-devices, device);
+
+if (! m-seat_without_graphics || ! device-seat-devices) {
+seat_add_to_gc_queue(device-seat);
+}
device_free(device);
} else {
@@ -372,9 +376,11 @@
goto finish;
}
-r = udev_enumerate_add_match_subsystem(e, graphics);
-if (r 0)
-goto finish;
+if (! m-seat_without_graphics) {
+r = udev_enumerate_add_match_subsystem(e, graphics);
+if (r 0)
+goto finish;
+}
r = udev_enumerate_add_match_tag(e, seat);
if (r 0)
@@ -1128,9 +1134,11 @@
if (r 0)
return r;
-r = udev_monitor_filter_add_match_subsystem_devtype(m-udev_seat_monitor, graphics, NULL);
-if (r 0)
-return r;
+if (! m-seat_without_graphics) {
+r = udev_monitor_filter_add_match_subsystem_devtype(m-udev_seat_monitor, graphics, NULL);
+if (r 0)
+return r;
+}
r = udev_monitor_enable_receiving(m-udev_seat_monitor);
if (r 0)
diff -Naur systemd-44.old/src/login/logind-gperf.gperf systemd-44/src/login/logind-gperf.gperf
--- systemd-44.old/src/login/logind-gperf.gperf 2012-11-15 22:31:43.0 +0400
+++ systemd-44/src/login/logind-gperf.gperf 2012-11-15 22:36:58.344888199 +0400
@@ -21,3 +21,4 @@
Login.Controllers, config_parse_strv, 0, offsetof(Manager, controllers)
Login.ResetControllers, config_parse_strv, 0, offsetof(Manager, reset_controllers)
Login.InhibitDelayMaxSec,config_parse_usec, 0, offsetof(Manager, inhibit_delay_max)
+Login.SeatWithoutGraphics,config_parse_bool,0, offsetof(Manager, seat_without_graphics)
diff -Naur systemd-44.old/src/login/logind.h systemd-44/src/login/logind.h
---
Re: [systemd-devel] logind: multiseat without framebuffer graphic cards
On Wed, 21.11.12 22:04, Олег Самарин (osamari...@gmail.com) wrote:
Hi!
I have a Fedora 17 system with two nvidia videocards, two screens, two
keyboards and two mouses. I've tried to setup multi-seat on it following
this article:
http://code.lexarcana.com/blog/2012/06/17/simple-multiseat-setup-on-fedora-17/.
But
without success.
I wasn#t aware of that blog story. I think the second part of it one can
just ignore entirely, though. The rules logind write out should be
entirely sufficient to put together multi-seat setups.
The article propose to create a new seat by attaching a framebuffer device to
the it:
Unfortunally, there are no any devices whose path end with /drm/card1 or
/graphics/fb1 in my system ('loginctl seat-status seat0' does not show any).
These paths arrive only after loading the open-source driver
(nouveau), but not with Nvidia proprietary driver.
Ahum, we wrote this with modern in-kernel drivers in mind, really. I
understand that people want to run this stuff with the closed-source
binary drivers, but due to the closed-source-ness this is really not
that high on my TODO list and is not as easy to implement as it sounds.
Furthermore, the right way of loading graphic driver is after starting
X-server, not before it. So logind should inform gdm about new seats
before gdm starts X-servers that loads nvidia driver.
My idea is
1. make static configuration of videocards and monitors in xorg.conf
Actually we have been working on eliminating this entirely. In F18 the
xorg.conf files we write are already much shorter, and we actually
intended to have them go away entirely already, which will probably
happen in F19.
2. dynamically add inputdevices according to the site udev rules
3. learn Xorg to select proper ServerLayout section according the -seat
parameter
I created two patches (one for systemd-44-21) and another for
xorg-x11-server-1.12.3-2) that implemented this idea.
These patches really work in the opposite direction we want things to
go. We want that X is capable of determine the hw to use from -seat, and
from -seat alone with no further configuration.
The first patch - systemd-logind-site-without-graphics - introduces
the new systemd-logind.conf option: SeatWithoutGraphics with default
value no. But the value yes allows logind to create a new seat by
attaching any device for it, not only graphics.
Well, but this is dangerous: how do you know when it is the right time
to send out the NewSeat bus signal? Note that our start-up is much
faster now than it used to be. In fact we will now end up starting gdm
at a time where the kernel drivers are not fully initialized yet, so
that graphics devices might not have shown up yet. Now, the kernel
graphics drivers generally guarantee us that the fb device is the last
one that shows up for each graphics card, hence we use he fb device as
indication that things are ready now. But if you disable this logic,
what do you use instead? Just because a USB mouse happened to have been
discovered before any graphics card this really shouldn't mean that we
immediately start an X server for it, which will subsequently fail
because it couldn't find the graphics card.
So, I am really not convinced that this all is desirable. I mean, I
understand why you are doing this, but this necessarily introduces
races, and is basically just a work-around for a closed-source binary
driver from a company that's a big dick towards Open Source.
I mean, I am not generally opposed to making changes when we notify the
DM that a new seat is available, but I am pretty sure that this global
switch is really not what we should be doing.
I think there are other ways thinkable, where we don't have to add
explicit nvidia-compatibility switches. For example, instead of
explicitly watching for fb devices to show up before we consider a seat
to be around, we could instead look for devices that are tagged with a
special tag (tag as in udev's TAG= construct) -- we'd then tag all fb
devices out-of-the-box this way, and people who want to use the nvidia
binary driver can attach that tag to some kernel device the nvidia
driver exposes, but I wouldn't have to care about that, and systemd
upstream wouldn't need to know what people do locally. And maybe you
could even convince Nvidia to ship the udev rule that attaches this tag
in their drivers. By doing things this way we'd not introduce the race
that your patch would introduce, but we'd not hardcode anything directly
to fb devices.
Note that in systemd we generally try to fix this things properly, and
not work-around things. Now, your global swicth didn't appear as a
proper fix to me, due to the race issues. But the solution with a udev
tag otoh sounds like a worthwile fix that makes logind cleaner -- and
which as a side-effect allows you to integrate things with your nvidia
driver.
Does that make some sense?
Lennart
--
Lennart Poettering - Red Hat, Inc.
