Bug 975079

Is it possible to submit both patches upstream? If wanted, I can also create a reviewboard entry myself.

Stefan,
thank you for your report and especially your patch. :)
Also thanks for noticing other seats can collide with Plymouth. I'm not sure if this is the right solution though. Can you explain why have you done it like this?
You're right about the XDG_SEAT variable. And of course the strcmp return value comparison is plain wrong, that was a stupid mistake from my side. I'll fix these two issues today in our repos.

I'm not thrilled about the idea of merging the patch with the upstream because the solution is one huge hack stacked on another bunch of hacks. KDM isn't really prepared to support multi-seat cleanly. Basically, the whole reserve displays idea is broken, causing us trouble with this.
Not mentioning the fact KDM won't survive the transition to Wayland if nobody steps up to maintain it. 

Thanks again,
Martin

Dr. Werner Fink <werner> was so nice to fix the plymouth issue, see https://bugzilla.novell.com/show_bug.cgi?id=809806#c18

@Martin : can you redo the plymouth and the multiseat patch, so there are only 2 patches we (openSUSE) have to track?

Hi Martin and Stefan!

As discussed previously in https://bugzilla.redhat.com/show_bug.cgi?id=884271, in my multiseat setup, I've observed a strange behavior with GDM: sometimes I get an inactive session for user logged in seat0. In this case, "loginctl show-session" shows VTNr=0 for seat0, which shouldn't be the expected behavior. To work around this, I have to unplug my USB hub (master of secondary seat), restart GDM and replug the hub.

I've rebuilt my own kdm package with both Stefan's patch, and kdm plymouth patch fix from openSUSE. In this case, I observe the same strange behavior described above: VTNr=0 for session opened in seat0, and XDG_SEAT not set for this session. If I unplug the hub, restart kdm, and replug the hub, the problem disappears until next reboot.

However, if I rebuild kdm with Stefan's patch only, but without that plymouth patch fix, and disable plymouth when my system boots, that strange behavior goes away, and I get active sessions for both seats as expected, even with my USB hub plugged at boot. No need to unplug hub/restart dm/replug hub anymore.

Thanks for the patches! Keep the good work!

Hi Laercio,

some comments about your setup and mine:

The latest version of the kdm multiseat patch includes setting the layout, so both "-seat" and "-layout" get the name of the seat as parameter. The layout parameter can then be used to configure everything else, just add an appropriate config file to xorg.conf.d with "ScreenLayout", "Screen", "Device" and "Monitor" sections referencing each other. In your case, this is

Section "Serverlayout"
  Identifier "seat1"
  Screen "Screen_sm501"
Endsection

In my kdmrc, I do not have any StaticServers (i.e., an empty list). I use the /usr/lib/systemd/systemd-multi-seat-x wrapper, and my ServerArgsLocal only includes -verbose and so on, so nothing seat specific.

Having anything seat specific in the args is problematic, as sometimes the first and sometimes the second seat is picked up first. Both reserved displays do have a ServerVT=7 resp ServerVT=8 option set.

Both of my seats do have custom names, e.g. seat-left and seat-right, and there is no seat0 left.

Stefan,

Instead of setting "ServerLayout"s in xorg.conf.d, I've patched my systemd-multi-seat-x wrapper so I can append my custom xorg.conf.__seatXXXX__ file to /run/systemd/multi-session-x/seatXXXX. The patch is available in https://bugzilla.redhat.com/attachment.cgi?id=764676.

I didn't notice that kdm now passes -layout option to X server. It will be useful when systemd-multi-seat-x goes away, but I still prefer passing a custom xorg.conf file via -config option, since it doesn't affect other seats, as xorg.conf.d approach could do.

In my current kdmrc, I have StaticServers=:0, ReserveServers=:1 and ServerVTs=-1 only. My ServerCmd is set to systemd-multi-seat-x and my ServerArgsLocal is not set at all. Moerover, I've set autologin users for each display/seat.

I'll try to make my kdmrc close to yours and post the results here.

Thanks!

Laercio,

Configs in xorg.conf.d wont affect other seats if you provide an explicit default screen section, e.g.:

Section "Screen"
  Identifier "Default Screen"
  Device "Default Device"
EndSection

Hello,
I tried running KDM with what Werner Fink posted in https://bugzilla.novell.com/show_bug.cgi?id=809806#c17 and the changes you provided.
Starting the system with the Plugable terminal I'm using for testing works good from what the user sees.
What really bugs me is what it actually does with the X displays and VTs:
 seat0 was on vt1 and :0. 
 seat-usb was on vt1 (the same? hmm...) and :3 after boot
Then, replugging it causes the following:
 1. iteration: no vt and :3
 2. iteration: no vt and :3
 3. iteration: X doesn't start
 4. iteration: vt2 and :2
 5. iteration: no vt and :2
 6. iteration: X doesn't start
 7. iteration: vt2 and :1
 8. iteration: no vt and :1
 9. and on: X doesn't start
So, there's still definitely something wrong. I'll try to debug the issue but can't promise anything.
If there's any time left, I'd be much happier if I could finally add the support to SDDM and package it for Fedora to make it a better alternative to KDM where I need to decrypt meaning of every variable that's been stuck in the code since the XDM days...

Hi Martin,

I think there is a problem if ServerVT is not set, see my last comment in
https://bugzilla.novell.com/show_bug.cgi?id=809806#c20

Confirmed.

My problems with VTNr=0 and inactive sessions in seat0 get solved when I explicitly set ServerVT for the secondary seat.

In my case, setting e.g. ServerVTs=-7 in general config and setting ServerVT=8 for display :1 is sufficient (no need to set ServerVT=7 for display :0).

If I set ServerVT=7 for one of the seats, but leave ServerVT unset for the other one and ServerVTs=-7 in general, my seat0 gets an inactive session (both X servers are running on vt7). However, if I restart kdm only (not reboot the system), the other seat automatically runs X server on vt8, and I get an active session for seat0 again.

The same behaviour was observed if I leave ServerVT unset for both seats, and leave ServerVTs=-7 in general section: when the system boots, I get an inactive session for seat0, but after restarting kdm, things get back to normal. No need to unplug my USB hub before restarting kdm.

So, the root of my problem with inactive sessions in seat0 is the fact that both X servers are running on the save vt when my system boots. I guess this is the same problem that occurs with gdm.

Now the question is: why both X servers are running on the same vt when my system boots? Could it be a problem with systemd?

NOTE: This test was run in openSUSE 12.3 with Stefan's packages for kdm, but I believe the same behaviour should be observed in Fedora 18.

Hi Laercio,

I have reworked the plymouth patch which should work in all cases.


1. It first builds a list with of available (unused by KDM/unreserved) VTs; in case of an explicit ServerVT, this VT ends up on the list.

2. Then plymouth is queried for its VT, if it is active and the VT is available, the VT is used for the new X server.

3. After that, the first available VT is used (which may be ServerVT, see 1.).

4. If none is found, and one server is currently quitting, the display is hooked into the dying display and will replace it.

Taking plymouth aside, the results should be the same as before, but the changed structure makes it much simpler to place the plymouth handling inbetween.


If you want to try it, it is my OBS repository.

BIG FAT WARNING - I had no time to test it, it compiles, thats it. It should work ... You better keep a known working kdm package around for downgrade.

Hi Stefan!

I've upgraded your packages and removed all explicit ServerVT options from my kdmrc, leaving only ServerVTs=-7 in general section.

Then I rebooted my computer and... IT WORKS!! Now both X servers are running in the right vts (display :0 in vt7 and display :1 in vt8).

Thank you very much for the help!!

One more thing:

In your kdm-multiseat-fix.diff, this piece of code

     grttalk.pipe = &grtproc.pipe;
     env = systemEnv(dupEnv(), 0);
+    if (td->systemd_seat)
+        env = setEnv(env, "XDG_SEAT", td->systemd_seat);
     if (gOpen(&grtproc, (char **)0, "_greet", env, name,
               greeterUID, td->greeterAuthFile, &td->gpipe))
         sessionExit(EX_UNMANAGE_DPY);

should be like this, for consistency:

     grttalk.pipe = &grtproc.pipe;
     env = systemEnv(dupEnv(), 0);
+#ifdef WITH_SYSTEMD
+    if (td->systemd_seat)
+        env = setEnv(env, "XDG_SEAT", td->systemd_seat);
+#endif
     if (gOpen(&grtproc, (char **)0, "_greet", env, name,
               greeterUID, td->greeterAuthFile, &td->gpipe))
         sessionExit(EX_UNMANAGE_DPY);

Otherwise, kdm compilation would fail when systemd support is disabled. You can see it in your OBS project by setting explicitly %with_multiseat to 0 in your spec file.

Hi Martin,

please refetch the patches from my repository:
https://build.opensuse.org/package/show/home:StefanBruens:branches:KDE:Release:410/kdebase4-workspace

Issues fixed:

- make sure plymouth handling only happens for the VT plymouth is running on
- add "#ifdef WITH_SYSTEMD" in all places necessary
- add "--wait" to "plymouth quit" to avoid a race condition between X server start and plymouth shutdown, necessary if X server is started without "-sharevts"

Created attachment 768424 [details]
Revised patch for automatic multiseat support

Original Martin's patch merged with Stefan's latest changes.

Hello Laercio and Stefan,
I'm sorry for responding this late and thank you both for your input!
I've just pushed the changed patches to our rawhide branch of kde-workspace (commit f7b192) with one more change - the wrapper doesn't need to be specified in kdmrc, KDM finds it on itself. 
However, it's still not 100% functional - using different VTs for different seats results in making the particular VT unavailable on both of the seats.
For example, when I have a session on VT1 on seat0 and a session on VT2 on seat-usb, I can't switch to VT2 on seat0. According to the how to on systemd freedesktop page, we should just ignore VT numbers for seats other than seat0.
Do you think otherwise? If I understand right, your use-case is a machine with two physical graphic cards, which could be different when compared to the USB terminal I'm using to test.
Thanks,
Martin

Hi Martin,

no problem for the delay, happens ...

Note that I have just updated the kdm plymouth patch yesterday, there was a problem when several X displays where used on a single seat (2. below). I think all use cases are working properly now, but lets test it a little bit more.

Remember we have several scenarios here:

1. Single seat, one session - trivial.
2. Single seat, multiple sessions, switching via CTRL+ALT+Fn
3. Multiple seats

One problem is that currently the kernel just knows one foreground console, which is (more or less, dont know) identical to/backed by seat0. Foreground =^ Active. Side note: kmscon will solve this problem ...

As soon as you do 2. above, the X server gets a signal someone wants to switch away from the active console, releases the graphics card, input devices an so an, and then tells the kernel it is ok to switch away. The second session gets an activation signal and now grabs the devices.

3. is different - remember, the can only be one active seat. So while the first X server is started on the active seat, the second one is started on an inactive seat. This is what "-sharevts" is actually doing - there is no VT switch during server startup, and the X server just picks up the available/configured devices (actually, it should implement "-seat" for all devices, not only input).

Although servers with "-sharevts" do not activate the VT, they still need one (today for no practical reason, but thats like it is). Therefor you cant switch to VT2 on seat0, thats denied by the X server running seat-usb.

If you do not specify "vtn" on the server command line, the server will pick one by itself (see the X code in hw/os-support/linux/lnx_init.c).  

Summary line:
You can have multiple VT users (X servers, splash screens, gettys) on seat0, you can switch between these. On every other seat, there is just on VT user, this VT is inactive, and you can not switch away from it.

Can you refetch the patches and test if everything works ok for you (given the limititations outlined above).

Hi Martin,

Sorry for the naîve question, but it seems the latest rawhide patch for multiseat in kdm (namely, for file kdm-workspace-4.10.xx/CMakeLists.txt) breaks backward compatibility with F18 and F19 (I have to edit it in order to rebuild kdm locally in my F19 installation). Will you backport it?

Latest F19 patch:
##############################################################################
--- kde-workspace-4.10.2/CMakeLists.txt.kdm_logind	2013-03-29 09:35:09.542235739 +0100
+++ kde-workspace-4.10.2/CMakeLists.txt	2013-04-10 15:17:35.941332970 +0200
@@ -76,6 +76,9 @@ if(Q_WS_X11)
   endif(NOT X11_Xcursor_FOUND)
 endif(Q_WS_X11)
 
+macro_optional_find_package(Systemd)
+macro_log_feature(SYSTEMD_FOUND "systemd" "Init and service manager for Linux" "http://www.freedesktop.org/wiki/Software/systemd" FALSE "" "Provides automatic multi-seat, session and power management features")
+
 macro_optional_find_package(GLIB2)
 macro_log_feature(GLIB2_FOUND "glib2" "Low-level core library for data structure handling, portability wrappers, etc." "http://www.gtk.org" FALSE "2.x" "Needed to build the kxkb keyboard map control program and provide XMMS support in the Now Playing Plasma data engine")
 
###############################################################################

Latest rawhide patch:
###############################################################################
diff -up kde-workspace-4.10.90/CMakeLists.txt.kdm_logind kde-workspace-4.10.90/CMakeLists.txt
--- kde-workspace-4.10.90/CMakeLists.txt.kdm_logind	2013-06-27 16:27:30.199895076 -0500
+++ kde-workspace-4.10.90/CMakeLists.txt	2013-06-27 16:30:25.167008304 -0500
@@ -128,6 +128,13 @@ if(Q_WS_X11)
   endif()
 endif(Q_WS_X11)
 
+macro_optional_find_package(Systemd)
+set_package_properties(Systemd PROPERTIES DESCRIPTION "Init and service manager for Linux"
+                       URL "http://www.freedesktop.org/wiki/Software/systemd"
+                       TYPE OPTIONAL
+                       PURPOSE "Provides automatic multi-seat, session and power management features"
+                      )
+
 macro_optional_find_package(GLIB2 2.0)
 set_package_properties(GLIB2 PROPERTIES DESCRIPTION "Low-level core library for data structure handling, portability wrappers, etc."
                        URL "http://www.gtk.org"
###############################################################################

Martin,

Never mind. This can be done by merging/resolving conflicts/commiting with fedpkg, right?

I've never used fedpkg before to rebuild my packages locally (instead, I've downloaded/written/edited full patches and run "rpmbuild -ba <package>"). Now I'm playing with fedpkg.

Yes, it is. Fedpkg is basically a git wrapper, so every package you download using it allows you to use git directly.

Martin,

Will your latest patches be released to F19/F18/F17? Any schedule?

Laercio,
I intended the patch to be used in the KDE SC 4.11 branch in the form as it is now before I solve all the remaining issues.
There's no particular schedule for fixing it or even backporting to 4.10 in F18/F19 (F17 is EOL now) and I have to admit it's currently a low priority to me unfortunately.

Hi guys!

Martin,

About your latest kdm multiseat patch update (with systemd-multi-seat-x autodetection), in its current form, autodetected systemd-multi-seat-x takes precedence over custom ServerCmd option in kdmrc. I would like to suggest a swap in the code, making custom ServerCmd take precedence over autodetected systemd-multi-seat-x.

Stefan,

About your latest work on kdm plymouth patch, I would like to suggest you another use case test. I'm explicitly disabling vt for my secondary seats (since they already have -sharevts option), setting ServerVT=-1 in the corresponding section in kdmrc. However, when I reboot my system, I get an inactive session for seat0 as before.

The command 'ps -FC X' reveals that my secondary seat X server runs on tty7, although no vtXX option is passed to X server, while my seat0 X server runs on no tty ("?" value in TTY column in 'ps' output), although it's passed vt7 option.

As before, restarting kdm service solves the problem.

Hi Laercio,

which version of the patch are you testing? (openSUSE, fedora, which repository, URL?)

Please attach your current kdmrc (strip with 'grep -v "^#"'), and provide the relevant output from /var/log/messages (grep kdm).

Stefan,

I'm using your latest kdm_plymouth.patch version in my OBS branch:

https://build.opensuse.org/package/show/home:lbssousa:branches:openSUSE:12.3:Update/kdebase4-workspace

I've also rebuilt locally my F19 kde-workspace packages with your latest patch. I see the same behavior in both F19 and openSUSE 12.3

Here is my 'ps -FC X' output:

UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
root      4345  4305  4 42117 35736   0 16:03 tty7     00:00:07 /usr/bin/X :1 -seat seat-thinnet -auth /var/lib/kdm/AuthFiles/A:1-4j9MZb -config /run/systemd/multi-session-x/seat-thinnet -sharevts
root      4417  4305  0 46540 25532   0 16:03 ?        00:00:00 /usr/bin/X :0 vt7 -nolisten tcp -seat seat0 -auth /var/lib/kdm/AuthFiles/A:0-xLfU7a







Here is my kdmrc (from openSUSE):

[General]
ConfigVersion=2.4
SUSEConfigVersion=2
StaticServers=:0
ReserveServers=:1
ServerVTs=-7
ConsoleTTYs=tty1,tty2,tty3,tty4,tty5,tty6
GreeterUID=kdm

[Xdmcp]

[Shutdown]


[X-*-Core]
ClientLogFile=.xsession-errors-%d

[X-*-Greeter]
LogoPixmap=/usr/share/kde4/apps/kdm/pics/kdelogo.png
MinShowUID=500
MaxShowUID=65000
ForgingSeed=1375709381
UseTheme=true

[X-:*-Core]
ServerCmd=/usr/lib/systemd/systemd-multi-seat-x
AutoLoginAgain=true
AutoLoginDelay=60

[X-:*-Greeter]
PreselectUser=Previous
FocusPasswd=true
LoginMode=DefaultLocal
AllowClose=false

[X-:0-Core]
TerminateServer=true
ClientLogFile=.xsession-errors

[X-:93-Core]
TerminateServer=true

[X-:0-Greeter]

[X-:1-Core]
ServerVT=-1
AutoLoginUser=aluno04
AutoLoginEnable=true




And here are my kdm-related entries in /var/log/messages:

2013-08-14T16:00:03.557804-03:00 linux-tzcm kdm_config[4210]: Multiple occurrences of section [General] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
2013-08-14T16:00:03.557930-03:00 linux-tzcm kdm_config[4210]: Multiple occurrences of section [Xdmcp] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
2013-08-14T16:00:03.557970-03:00 linux-tzcm kdm_config[4210]: Multiple occurrences of section [X-*-Core] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
2013-08-14T16:00:03.558010-03:00 linux-tzcm kdm_config[4210]: Multiple occurrences of section [X-*-Greeter] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
2013-08-14T16:00:03.558055-03:00 linux-tzcm kdm_config[4210]: Multiple occurrences of key 'UseTheme' in section [X-*-Greeter] of /usr/share/kde4/config/kdm/kdmrc
2013-08-14T16:00:03.558137-03:00 linux-tzcm kdm_config[4210]: Multiple occurrences of section [X-:*-Core] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
2013-08-14T16:00:03.558177-03:00 linux-tzcm kdm_config[4210]: Multiple occurrences of section [X-:0-Core] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
2013-08-14T16:00:03.563226-03:00 linux-tzcm kdm[4209]: plymouth is running
2013-08-14T16:00:03.566108-03:00 linux-tzcm kdm[4209]: plymouth is active on VT 7, reusing for :0
2013-08-14T16:00:03.566208-03:00 linux-tzcm kdm[4209]: plymouth should quit after server startup
2013-08-14T16:00:04.708403-03:00 linux-tzcm kdm[4209]: Quitting Plymouth with transition
2013-08-14T16:00:04.797301-03:00 linux-tzcm kdm[4209]: Is Plymouth still running? no
2013-08-14T16:00:05.059135-03:00 linux-tzcm kdm[4209]: Quitting Plymouth with transition
2013-08-14T16:00:05.062394-03:00 linux-tzcm kdm[4209]: Is Plymouth still running? no
2013-08-14T16:00:06.562602-03:00 linux-tzcm kdm_greet[4322]: Cannot load /usr/share/kde4/apps/kdm/faces/.default.face: Arquivo ou diretório não encontrado
2013-08-14T16:00:06.562633-03:00 linux-tzcm kdm_greet[4327]: Cannot load /usr/share/kde4/apps/kdm/faces/.default.face: Arquivo ou diretório não encontrado
2013-08-14T16:01:06.986556-03:00 linux-tzcm kdm: :0[4326]: pam_unix(xdm-np:session): session opened for user aluno03 by (uid=0)
2013-08-14T16:01:07.060196-03:00 linux-tzcm kdm: :1[4320]: pam_unix(xdm-np:session): session opened for user aluno04 by (uid=0)
2013-08-14T16:03:37.701598-03:00 linux-tzcm kdm_config[4306]: Multiple occurrences of section [General] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
2013-08-14T16:03:37.701718-03:00 linux-tzcm kdm_config[4306]: Multiple occurrences of section [Xdmcp] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
2013-08-14T16:03:37.702194-03:00 linux-tzcm kdm_config[4306]: Multiple occurrences of section [X-*-Core] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
2013-08-14T16:03:37.702257-03:00 linux-tzcm kdm_config[4306]: Multiple occurrences of section [X-*-Greeter] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
2013-08-14T16:03:37.702303-03:00 linux-tzcm kdm_config[4306]: Multiple occurrences of key 'UseTheme' in section [X-*-Greeter] of /usr/share/kde4/config/kdm/kdmrc
2013-08-14T16:03:37.702372-03:00 linux-tzcm kdm_config[4306]: Multiple occurrences of section [X-:*-Core] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
2013-08-14T16:03:37.702409-03:00 linux-tzcm kdm_config[4306]: Multiple occurrences of section [X-:0-Core] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
2013-08-14T16:03:37.721866-03:00 linux-tzcm kdm[4305]: plymouth is running
2013-08-14T16:03:37.725403-03:00 linux-tzcm kdm[4305]: plymouth is active on VT 7, reusing for :0
2013-08-14T16:03:37.725497-03:00 linux-tzcm kdm[4305]: plymouth should quit after server startup
2013-08-14T16:03:38.898246-03:00 linux-tzcm kdm[4305]: Quitting Plymouth with transition
2013-08-14T16:03:38.984121-03:00 linux-tzcm kdm[4305]: Is Plymouth still running? no
2013-08-14T16:03:39.244968-03:00 linux-tzcm kdm[4305]: Quitting Plymouth with transition
2013-08-14T16:03:39.247672-03:00 linux-tzcm kdm[4305]: Is Plymouth still running? no
2013-08-14T16:03:40.746050-03:00 linux-tzcm kdm_greet[4418]: Cannot load /usr/share/kde4/apps/kdm/faces/.default.face: Arquivo ou diretório não encontrado
2013-08-14T16:03:40.746113-03:00 linux-tzcm kdm_greet[4423]: Cannot load /usr/share/kde4/apps/kdm/faces/.default.face: Arquivo ou diretório não encontrado
2013-08-14T16:04:40.950853-03:00 linux-tzcm kdm: :0[4422]: pam_unix(xdm-np:session): session opened for user aluno03 by (uid=0)
2013-08-14T16:04:41.027008-03:00 linux-tzcm kdm: :1[4416]: pam_unix(xdm-np:session): session opened for user aluno04 by (uid=0)

One more thing: I've seen that the problem above occurs even when I disable Plymouth at boot (e.g. setting splash=0 in openSUSE or removing rhgb option in Fedora).

One possible source of trouble is the fact that KDM seems to launch X servers in an asynchronous way. For example, if I have in my kdmrc something like

StaticServers=:0,:90,:7
ReserveServers=:1,:2,:56,:10

it's not clear in which order the X servers are launched (at least in the first time, when my system boots). In my example in the comment #25, the :1 X server has a lower PID than :0 one, which leads me to think :1 was launched first, "stealing" /dev/tty7 from :0 X server.

For my purposes, KDM (or any other DM) should launch X servers in a given order, starting with static servers, before any dynamic server. In the example above, KDM should launch, in this order, :0 server, :90 server, :7 server, and then any other dynamic server, reserving :1 for the first server launched on demand, :2 for the second one, :56 for the third one, and :10 for the fourth one.

By default KDM launches servers in the opposite order specified in the StaticServers list (most probably because each entry is prepended to a single linked list during config parsing).

I have added additional logic to the plymouth patch which forces starting the server which matches plymouth' VT first, otherwise VT handover from plymouth to X fails.

I do not know why the second X server is grabbing VT7 despite given "-sharevts", I consider this a bug in the X server.

I don't know when I will be able to look into this, will be offline until monday.

Hi Laercio, yes, this approach I used is how it was done in GDM when I first read the multiseat code there and it isn't the completely correct one. I think it'd be best to just have an option setting ServerCmd for other seats than seat0... and maybe even to be able to turn off the multiseat support completely.
I'm not promising anything but it's possible I'll add them to the configuration file over time but I'd rather focus on fixing SDDM now.

@Laercio:
There was a bug in the plymouth patch which started any dynamic seat server before the on replacing plymouth.

Should be fixed in the latest patch incarnation.

Stefan,

Nice catch!

I've updated kdm packages with your latest kdm_plymout.patch update. It's fully working now. Secondary seats no longer "steal" TTY from seat0.

Thank you!

This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20

kde-workspace-4.11.1-3.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/kde-workspace-4.11.1-3.fc20

kde-workspace-4.11.1-3.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/kde-workspace-4.11.1-3.fc19

Package kde-workspace-4.11.1-3.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kde-workspace-4.11.1-3.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-17713/kde-workspace-4.11.1-3.fc19
then log in and leave karma (feedback).

kde-workspace-4.11.1-3.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

kde-workspace-4.11.1-3.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.